Welcome Guest, Not a member yet? Register   Sign In
Using PHP Session and the CI Session together

[eluser]Bart v B[/eluser]
[quote author="bretticus" date="1282697461"]Ummm, this is for remembering the user's theme it appears. Are you trying to avoid a database? Why store this as a config item? Are you programing an installer?[/quote]

I am not the topic starter, but i am trying to make a installer.
Mabye better to say a dynamic solution per domain driven.

Just one CI installation en from that things must be arranged with the domain name..

@Bart v B There's really no "CodeIgniter way" of writing files other than using the File Helper. You could use the write_file('path', $data) function in particular.

I'd use PHP's native function: var_export() to write your array variables (config files are just arrays that are loaded each time) to code before saving to a config file. Also, you will have to come up with someway of loading the config file based on the same convention you wrote it (see Loading a Config File in the manual.)

[eluser]Bart v B[/eluser]

Thnx for the tips i go and see if i can do something with your tips.


@bretticus I'm not programing an installer, but I try to make my site as configurable as possible. So the data should be recovered from the DB, not from a configuration file.

I'm trying with the session, and I solved the problem, but of course I have the problem of size.

Could I use PHP's session whith the CI's session? So I could save the configuration data in one, and user data in the other.

Is the data really configuration data? I mean there's more than 4k worth? Maybe this is more than I anticipated. You can try enabling database sessions. I assume (because, honestly, I don't know at the moment for sure) that session data stored in the database is not also stored in the cookie. If you are having issues with the 4k limit on cookie size, give that a try. I am not aware of any significant limit on session data size using native PHP sessions, so there's an option also (no reason to use both IMHO.) Don't forget about the many caching options for PHP. For example, memcache was designed to cache data in memory to avoid trips to the database. You can always use one of the many op code/caching options in PHP to store your config data.


Your assumption is correct.

If you use database sessions (and you should, do not store user data client side!), the size of the cookie is limited by the size of the user_data column in your session table, and only the session_id, user_agent, IP address and last_activity timestamp is written to the cookie. These fields are needed to find the correct session record. Also, don't forget to encrypt the session cookie, so the session_id (and other fields) can't be retrieved and used for session hijacking.

Thanks @WanWizard. I had always assumed so because I never use cookie based sessions (even with encryption turned on.) Never took the time to find out (and wasn't going to poke around at the time of writing my reply.) Thanks.

I just want to reiterate. It's not a great idea to store significant amounts of data in a database session either (I mean, you did say that you didn't want to make another trip to he database after all!) If you are storing queries, store them with op cache extensions (APC, memcache, etc.) If they are session specific, you could hash the username (or just use the session id) as keys for op cache. If you love the session idea, I'd recommend using PHP's session with memcached (this is only possible if your server is not shared. That is, you or someone in your company, has root access to do the set up.)

Of course, if the data isn't too large, even database enabled CI sessions are okay (because returning one column from one row with a primary key is always faster than performing a more complex query.)

It all depends on your environment.

In general, a database engine is a lot more efficient in I/O than PHP's native file I/O code (unless it's very badly configured or overloaded (which happens a lot in a shared environment)). Database sessions give you added benefits as well, such as a list of all logged in (or active) users (within a given time frame).

However, there is always a point where it becomes wise to enable caching, switch from database to file, switch from file to memory, etc. I find it generally very difficult to give 'general' advice about when you should do what. As suggestions, I fully agree with your reply.

Note that the CI session library could need some improvements. Currently, every time you call set_userdata(), it updates the session record. I've extended the session library so it only does two I/O's: one read when the session library loads (and an insert when the session doesn't exist), and one update at the end of every page request. You also have to force a write when you do a redirect, otherwise you lose the variables set before the redirect.

Theme © iAndrew 2016 - Forum software by © MyBB