[eluser]oribani[/eluser]
First, let me commend the CI team on a nicely written user guide: it's overall an easy, quick read but at the same time fairly comprehensive -- good balance!
Elsewhere here, I pointed out some inconsistencies in the user guide (specifically the confusing use instructions on how to extend/replace "native libraries" and "core classes" on two successive pages when, from what I can tell, the two are the same thing).
I got no small amount of grief for pointing that out, which is too bad, so I was less motivated to note the less drastic problems (I think there is a mis-use of "its" or "it's" somewhere early on in the guide, and I think it was the Active Record page that had several copy-paste errors maybe in all those where_in, or_where_in, like, or_like, or_not_like... methods -- nothing major, anyway).
But I did think it was worth noting that the Form Helper documentation, specifically for the set_value, set_select, and related functions was unclear. Because all it says is "Permits you to set the value of an input form or textarea.", at first I thought it grabs the value by looking for a variable named whatever you give as the first parameter. Turns out that it looks directly into $_POST for a key name based on that first parameter. Fine, good stuff, but even the code documentation is more clear about where the value comes from: "Grabs a value from the POST array for the specified field so you can re-populate an input field or textarea." Or even the docs from the Form Validator class: "Permits you to repopulate a form field with the value it was submitted with, or, if that value doesn't exist, with the default"
The Session library seems to have a lot of issues that are talked about in threads all over the place. One thing to do might be to have a definitive location for the status of that library, since some features from various third-party replacements for it seem to have been back-ported into it.
One thing I found quite unclear about its documentation is where the session data goes when you enable a database for session storage. That is, I only learned from reading a lot of forum threads that the cookie only apparently holds the session ID and the database holds all other data. In that case, the skimpy cookie size limitation is not an issue, and I don't believe this is pointed out in the user guide at all.
Also, I find it HIGHLY irresponsible that there are no warnings in the Session library documentation that CI does not support non-persistent cookies. For anyone building an application with sensitive data, this is a gaping security hole: an unauthorized user could re-open a closed browser and get right into someone's account because CI assumes you want two-year cookies if you zero out the expiration date. Not only is it stunning that people who coded a pretty decent framework with lots of flexibility would lock you in like this.... be that as it may, it is definitely not responsible not to put up a warning about this at the top of the Session user guide page.
Maybe for the time being, that page should point to the Session library replacements listed in the wiki, at least until the native code addresses its more serious problems.
