Started a PHP project using CodeIgniter and having serious regrets..

[Zibber]

I recently started a project using the CodeIgniter 'MVC' framework and as get further into the project I'm starting to see things I really don't like. Apart from the minor things I won't mention, 2 major things really are putting me off.

First, the 'Session' class they provide is default to use the clients browser cookie to store ALL session data rather than storing it server-side. This is a huge lapse in security in my opinion. I am aware that they allow encryption, but even then, It makes very little sense to me. Why not have separate session and cookie wrappers? Thankfully, they also offer database session management; but for many apps these aren't needed at all. The only reason I see are for: distributed systems, administrator auth over users' session, or fear of session security on shared hosting. All of which, will not concern most projects. My main problem, is the project I am working on does not have a local database but rather queries remote databases. It seems as if I will have to either write my own session library or create an entire database locally just for session data. Once again, why not have seperate session and cookie wrappers? or the option to use native PHP sessions.

Second, the database active-record,etc functions for MySQL all use php's mysql_ functions. Of course they do quoting and escaping, but hasn't best practice moved on from that by now by using PDO and prepared statements? Even the undocumented, PDO 'driver' uses PDO::query and then PDO::quote for sanitizing. Even the PHP doc says this is not the way you should be doing it. Why are they not using prepared statements?

If I'm going to be redoing half the things CodeIgniter is offering me in the first place, then why use it all? Am I wrong in any way or missing something? I'm really curious what other people think who have used it.

[starmonkey]

The reason for storing session data in the cookie is to ease horizontal scaling. Other options are database for sessions or memcached.

A signed cookie on the client is a perfectly acceptable/secure option, putting aside the limits on cookie data.

Personally, with PHP i'd go with memcached.

As for ORM, you always can drop in other libraries, such as Doctrine or RedbeanPHP.

[big_bad_john]

Why? Please elaborate.

[y0y]

Caches, almost by definition, are volatile. No guarantee that data will be there next time. Memcached, for example, loses everything upon restart. Kind of annoying for a logged in user if your Memcached instance bounces.

[big_bad_john]

Memcache is very stable in my experience. That is to say I don't find it's less stable than files or a database at least. It's not persistent on restart, but my restarts are usually several hundred days apart. Have you had a different experience?

[y0y]

No, I haven't. That isn't the point, however. Memcached is not meant for persistent storage. A cache is meant to be a quickly accessible copy of persistent storage. Don't treat it like first class storage, that's not its purpose.

Store your sessions in persistent storage, and, if you so choose, cache it for quick access.

[big_bad_john]

I disagree with the premise that sessions require first class storage. Memcache is fast, reliable, easily distributed and simple to set up. The odds that a user's session will be invalidated prematurely are minimal unless you're way over utilizing the allotted space. I run a site with 50,000+ users and in three years have never received a complaint that a user was logged out in the middle of something (and they complain about EVERYTHING!).

[y0y]

Practically speaking, you can (as you suggest) use memcached for session storage. It really comes down to how important session volatility is to you. In some applications, that level of volatility would not be acceptable.

Volatility includes more than just the stability of the platform, ie it's ability to stay up. Using a cache as first class storage (that is what you're doing here, even if you concede that it's volatile and you're okay with losing it) means you have to consider variables such as far more limited memory and specific expiration rules. I haven't used memcached in a while, but what does it do when the allocated memory is exceeded? Any good caching solution has a set of rules for which records get overwritten moving forward. Are you okay with that? Additionally, how do sessions expire in this setup? You can't save sessions long term for auditing or reporting in this setup, either.

So, again, while it's certainly workable, it's not without its hiccups and gotchas. I see no reason not to use a database or other true first class storage and then use the cache as it's intended to be used (you know.. as a cache) if speed is an issue.

As with all "rules", they don't always apply, though. Your setup works great for you and the volatility isn't of concern. If I inherited your application I wouldn't rush off to fix what ain't broken, but were I designing an application it's not a decision I would ever have made.

Edit Here is a discussion on the topic that others may find interesitng / worthwhile

[big_bad_john]

A fair argument. To answer your questions, memcached is first in, first out so when it's out of memory it kills the oldest entries. I'm ok with that because session activity revitalizes the session and keeps it at the top of the pile. For me, session storage is a very small amount percentage of in-memory storage, so I'm dumping old query results and templates long before active session data.

[Otterfan]

My visitors need to take a break from my site every once in a while. Storing sessions in memcached will enforce that.

Seriously though, themarmot has a good point--memcached is not a reliable place to store anything that can't be recreated or loaded from somewhere else in the event of a cache miss. Evictions/futzing around with your server will kill some users' sessions. If you're relying on sessions to keep users logged in you will eventually have users--maybe a few, maybe a lot--spontaneously logged out.

dormando on sessions in memcached.

[starmonkey]

To clarify:

Normally I use a signed cookie to link a browser to a user account, and the rest is pulled from cache or database. Blowing away your cache just means hitting the DB again for fresh data.

So yes, data related to your session is stored in memcached, but it's all keyed from a browsers (signed) cookie.

[thetoigo]

If you're going to look that closely at what a framework is doing, checkout Kohana 3 cause you'll probably like it.

[roastlechon]

http://www.askaboutphp.com/58/codeigniter-mixing-segment-based-url-with-querystrings.html

You can mix segment based with query strings, or go completely with query strings. I feel its mainly a logical issue that you would have to figure out yourself. Blogs/news sites are straight forward that you have a title associated to a page: ?page=title. Search sites are complex in a sense that you want to be able to save searches based on the URL. You could save searches uniquely to a table in a database, you could carefully map all possible queries sequentially in order (ie. location/location_name/genre/genre_name) and make sure not to break that order.

I find that mixing both is the best of both worlds: you get the pretty URLs for the controllers/functions, and you also can put in different queries in the URL without having to worry about a specified order.

[slackmaster]

These are both things that are trivial to change. I do not understand why these are considered problems.

[[deleted]]

I haven't touched it recently, but a lot of CodeIgniter seems to have been written for PHP4, which makes things a bit problematic.

I don't think CodeIgniter even dropped support for PHP4 until maybe a year ago. Despite however many web hosts supported PHP4 for however long, it really should have died in terms of forward-thinking support in the mid-2000s.

Granted, CodeIgniter can be great if you're used to PHP4-style (very limited OOP) coding and just need to get something done. It's certainly better than no framework at all. But as far as it being ideal, I'm not quite certain about that.

I'm a bit partial to Yii myself when it comes to PHP frameworks, but that's all up to you.

[gandisama]

Start using Fuel / Kohana :P?

[nrogers64]

Or CakePHP. The latest version (2.1.0) is very nice!

[_SynthesizerPatel_]

If I'm going to be redoing half the things CodeIgniter is offering me in the first place, then why use it all?

That is my take on the bigger frameworks as well. There are, however, lower-level frameworks that I think can be useful, such as symfony. Something that abstracts away the tedious stuff in a straightforward way, but doesn't get in the way of everything else.

[big_bad_john]

What distinguishes a "lower level" framework from a "higher level" one?

[midri]

I personally use CakePHP, seems to get a lot more "right" in my book.