Community Feature Requests

[eluser]Derek Jones[/eluser]
Rick, we plan on providing official channels for communication like this - as you mention UserVoice is one option, and it's the most likely choice. We won't be leaving it in the wind or <em>only</em> to the deputies' devices on communicating with the community. And it's going to rely on professional discord between deputies to keep the codebase honest. I'd be worried if everyone involved all had the same ideas and they went without challenge.

[eluser]WanWizard[/eluser]
For every type of dialog there's a suitable platform. typewith.me isn't amongst them (unless you're really collaborating using a document).

For open discussion, use either IRC (very direct), the forum (slower response), a video/voice conference, or meet in person. For features, issues and/or bug tracking, use a bug tracker. Preferably one with a proper comment tracking system.

And yes, whatever you use, as soon as you make something public, you will get some noise. On every bug tracker I run I have to close issues with 'wontfix', 'worksforme' or 'rejected'. Comes with the job, that's how a community project works.

On the other hand, contrary to popular believe, a community project isn't necessarily a democracy (or anarchie). In order to stick to the roadmap, to maintain stability, to adhere to guidelines, or to maintain standards, requests can be rejected. In the end, it's beneficial to the users. Let's face it, CI's strengh has always been it's stability and easy upgrade path. You will only archieve that with proper planning, and good project management.

[eluser]skunkbad[/eluser]
My list (which I have my own solutions for but would be nice to see in CI by default):

1) Fix $_GET. I don't use it much, but at least if you fix it we won't have all the posts in the forum.

2) Create a real $_SESSION library. Sure, you may not like $_SESSION, but it's as much a part of development as $_GET. Yes, there are issues with $_SESSION, but same with cookies. It should be our choice.

3) Have better HTTPS support in regards to the url helper functions, anchor function, base_url, etc.

4) Make better custom 404/error pages. I make my own quite nicely, but these pages should be like that out of the box.

5) Pagination that works with non-database type data. Right now the offset doesn't allow for us to paginate stuff that doesn't come out of a query.

I could probably think of more... but will anyone care?

[eluser]InsiteFX[/eluser]
For Autoload I would go with the new SPL_Autoload methods.

My $0.02

InsiteFX

[eluser]adamp1[/eluser]
I think Rick Jolly has got it perfectly. This branch shouldn't be to add new authentication features or other massive new features, yes some little add ons and improvements but it should be making sure the architecture is perfect/simple and easy to expand upon.

Any site I make I find I use a modular design since having 20+ controllers in the controller folder just makes maintenance ugly. I'm not saying it should have something like HMVC but I think this branch should concentrate on making developing a site quick, easy and maintainable. Everything which CI was when I started using it.

[eluser]Phil Sturgeon[/eluser]
[quote author="Rick Jolly" date="1290568792"]Phil, if you "know for a fact" what will be included, then why start this discussion? [/quote]

I don't know for a fact what will be included, but I know several things that wont. ORM for example, is incredibly unlikely to be included. The things I deleted were only deleted after a vote of all the people on the document (in chat at the time).

[quote author="Rick Jolly" date="1290568792"]Typewith.me, the feature request format you chose, does not facilitate an open community discussion. Something like uservoice allows the most popular ideas to rise to the top, not necessarily Phil's or even Ellislab's ideas. Uservoice also allows healthy debate.[/quote]

UserVoice is great, I use it myself. Going forwards that would be great, but not a lot different than the forums, issue tracker, etc other than the ability to vote items up to gauge importance.

[quote author="WanWizard" date="1290573006"]For every type of dialog there's a suitable platform. typewith.me isn't amongst them (unless you're really collaborating using a document).

For open discussion, use either IRC (very direct), the forum (slower response), a video/voice conference, or meet in person. For features, issues and/or bug tracking, use a bug tracker. Preferably one with a proper comment tracking system.[/quote]

TypeWith.me can be very effective, but only when everyone is online. We had the room maxed and we're all collaboratively discussing features and plans. Me, Micheal Wales, n0xie, Elliot Haughin, Adam Griffiths were all agreed on the majority of changes after some discussion.

I posted it in here after people suggested I should share what we talked about for further discussion.

Some are small and likely, some are larger and more far-fetched. Things like user-auth are incredibly unlikely to go in but its good to think about the features and plan them a little bit.

Using this document was not meant to be an ongoing solution as it would clearly become unmanageable. It simply helped me to have a conversation with some interested CodeIgniter developers and plan what sort of things they'd like to see happen. This worked for me to give me a refreshed idea of what people want and how, so in that instance alone it was helpful.

I'm not sure where this negative energy is coming from. I tried something out to see what was happening, I never pretended to be "The Voice of EllisLab" and I was not trying to take anything over, I just wanted to have a chat and plan some features about CodeIgniter. Something we should all be happy with doing

[eluser]Phil Sturgeon[/eluser]
[quote author="skunkbad" date="1290595481"]3) Have better HTTPS support in regards to the url helper functions, anchor function, base_url, etc.[/quote]

Something like this?

http://sajjadhossain.com/2008/10/27/ssl-...deigniter/

[quote author="skunkbad" date="1290595481"]4) Make better custom 404/error pages. I make my own quite nicely, but these pages should be like that out of the box.[/quote]

I know what you mean, but I think with the addition of $route['404'] this is now much less of an issue? You can map a 404'ed request through to errors/error_404 and have it loading just like any other page/controller in your system.

[quote author="skunkbad" date="1290595481"]5) Pagination that works with non-database type data. Right now the offset doesn't allow for us to paginate stuff that doesn't come out of a query.[/quote]

I suppose the closest you'd get here is some array_slice()? Could you explain the problem a little more?

[quote author="skunkbad" date="1290595481"]I could probably think of more... but will anyone care?[/quote]

I do

[eluser]WanWizard[/eluser]
If talking about an open discussion/brainstorm, it's just a bit frustrating that you spend some time adding info, only to find out half an hour later that someone didn't thought it's wasn't interesting, and just deleted it.

Only speaking for myself, my comments are absolutely not mend to be negative, on the contrary.

I'm only stating that, given my experience in 20+ years of managing projects, and 10 years of OSS involvement, I think that organisation, toolkit, procedures, clean communications and a strictly managed roadmap all are critical success factors...

[eluser]Michael Wales[/eluser]

I think that organisation, toolkit, procedures, clean communications and a strictly managed roadmap all are critical success factors…

Most definitely - none of which CodeIgniter has had (or at least publicly) before. Give it some time - view the document Phil linked to as the notes from a discussion a group of guys had, nothing more. It is merely a subset of the things this community desires, from a subset of the community.

[eluser]skunkbad[/eluser]
[quote author="Phil Sturgeon" date="1290621845"][quote author="skunkbad" date="1290595481"]3) Have better HTTPS support in regards to the url helper functions, anchor function, base_url, etc.[/quote]

Something like this?

http://sajjadhossain.com/2008/10/27/ssl-...deigniter/

[quote author="skunkbad" date="1290595481"]4) Make better custom 404/error pages. I make my own quite nicely, but these pages should be like that out of the box.[/quote]

I know what you mean, but I think with the addition of $route['404'] this is now much less of an issue? You can map a 404'ed request through to errors/error_404 and have it loading just like any other page/controller in your system.

[quote author="skunkbad" date="1290595481"]5) Pagination that works with non-database type data. Right now the offset doesn't allow for us to paginate stuff that doesn't come out of a query.[/quote]

I suppose the closest you'd get here is some array_slice()? Could you explain the problem a little more?

[quote author="skunkbad" date="1290595481"]I could probably think of more... but will anyone care?[/quote]

I do [/quote]

In regards to HTTPS and the link provided, yes. I use something similar. It makes sense that the framework would have this built in.

Haven't played with $route['404']. Is this new in 2.0? Is it documented anywhere in the official user guide?
,]

The first time I tried to paginate something that wasn't a db result, it was clear that the offset used by the pagination library made it impossible to use without some custom extension. I then searched the forum and saw that other people were saying the same thing, so I just did the pagination on my own. Maybe there is an easy way to do the non-db pagination, but it isn't documented. Do you know what I mean now?

Now for more:

6) The cart class is like a tease. If CI is dedicated to e-commerce, then it would be nice to have a checkout class that allowed developers to add in shipping / gateway / tax modules as needed. I'm sure the community would love to have a checkout module library so we could share these modules. Yes, I know of the wiki, but I'm trying to emphasize how nice it would be to have a CI checkout class. We have a smiley helper and a calendar class. How much more useful would a checkout class be? Working together with the cart class, it could ensure that somebody wasn't trying to cheat the system, and it could handle accepting either credit card data, paypal redirect, both, or whatever. Having built my own Community Cart, I know there's a ton of work, and would love to have not spent so many hours doing it.

7) Better documentation on how to handle errors when using both the form validation class and the uploader class at once. In fact, it is not very simple to merge the two (at least for me). I've came up with my own way of doing what I need to do here, but I wish it was easier.

Anyways, being called by the wife....