Eric Mann

I don’t know what plugin this is that’s having an issue, but no, the plugin isn’t that kind of backwards compatible.

The wp_session object itself is an array and pulling items out of it will return the item that’s stored. It sound like the tarot_cards item in the session is <i>already</i> an array. The old toArray() method was used to convert an array-like object to an array and is no longer needed here at all.

I should add this to the FAQ, but there are some quick instructions listed with the underlying Sessionz library: https://github.com/ericmann/sessionz#encryptionhandler. Copying here for simplicity …

Sessions stored on disk (the default implementation) or in a separate storage system (Memcache, MySQL, or similar) should be encrypted at rest. This handler will automatically encrypt any information passing through it on write and decrypt data on read. It does not store data on its own.

This handler requires a symmetric encryption key when it’s instantiated. This key should be an ASCII-safe string, 32 bytes in length. You can easily use Defuse PHP Encryption (a dependency of this library) to generate a new key:

$rawKey = Defuse\Crypto\Key::createNewRandomKey();
$key = $rawKey->saveToAsciiSafeString();

Garbage collection of sessions in PHP is somewhat random. It’s managed by two other INI settings: session.gc_divisor (default 100) and session.gc_probability (default 1).

(See: http://php.net/manual/en/session.configuration.php#ini.session.gc-probability)

There is a session.gc_probability / session.gc_divisor chance that garbage collection will run on any given request. By default, that means only a 1% chance of garbage collection running.

Why this isn’t more deterministic is beyond me, but I’m sure there’s a reason PHP is built that way.

I’m super curious what other code is calling session_start(), but that’s beside the point.

I added some more defensive coding in v3.0.3 (just released) that checks to see if the session is active before calling session_start(). If it’s already been started by some other code, then I won’t run a duplicate call.

The session_start() call will either start a new session or resume an existing one. Without that call, $_SESSION won’t be populated at all. See http://php.net/manual/en/function.session-start.php for reference.

Versions above 2.0 use a custom database table to avoid overloading options. Versions above 3.0 use native sessions so you can leverage the standard PHP session cookie. The latest versions should play nicely with Pagely and other hosts.

These issues were the driving force between rewriting things in versions 2 and 3. Version 2.0 introduced a separate database table (for more efficient reads/writes/cleanups). Version 3.0 refactored the entire system to use native PHP sessions instead of a custom object (that was prone to duplicating effort in certain places).

Almost all of the configuration can now be handled with PHP’s runtime INI configuration, and the custom DB table can be purged as often as needed (even by an external system, if necessary).

The plugin no longer uses a _wp_session cookie and, as of v3.0, uses native PHP sessions (and the standard PHPSESSID cookie). Sessions start by default on the plugins_loaded event if not started some other way.

Thinking out loud … you <i>might</i> be able to unhook that particular event, then wire up session_start() where you need it explicitly. As for destroying a session, the default session_destroy() will purge the data and kill the cookie.