Eric Mann

ollieford: Don’t hijack old, resolved topics. Start a new thread please.

Yes, the API did change a slightly.

In the older version, sessions were written on every page load, regardless if the data changed in them at all. I worked with some other developers to fix this so that sessions are only written if something changes.

In an ideal (i.e. high-traffic environment), this is what happens:

1. When a new visitor hits your site, a new session is created for them and stored in the database. The session ID, exipiration, and “variant” is stored in a cookie in the user’s browser.
2. When the user comes back to the site, the session is read into the cache (APC or Memcached or something else, depending on your configuration) if it’s still valid.
3. If the session is unexpired, but past the timestamp recorded as a variant, the expiration is updated so things aren’t cleared out too quickly (This is 1 database write to update the exipiration. But it won’t occur on every page load … and you can set the timeout before it does happen through a filter.
4. If nothing changes during this page load (i.e. nothing added to a cart, no options changed), then nothing further happens.
5. When the user revisits your site, the session is loaded from the cache (no roundtrip to the database).
6. If any session data changes, the session is marked as “dirty.”
7. Dirty sessions are re-written to the database at the end of the request.

One big change did occur with the update – sessions are no longer explicitly available in the global namespace as $wp_session. Instead, you’ll need to:

• Explicitly define $wp_session = WP_Session::get_instance(); inside any session-dependent functions.
• OR set a global $wp_session equal to WP_Session::get_instance() inside a function hooked to either init or wp_session_start.

The reasoning behind this change was primarily to keep the global namespace clean and to prevent installing any hidden dependencies in code. A lot of people freaked out that WP_Session was implemented as a singleton in the first place. A second chorus protested to storing it in a global variable as well. This qas a compromise.

There is no feature yet to allow restricting file type uploads. However, I can investigate that for a future version.

Also, this thread shows you’re running WordPress version 3.0.4. WP Publication Archive is not supported for that old of a WordPress version.

Yes, you can do this. The layout (the output of the shortcode) is controlled by template.wppa_publication_list.php in the /includes directory. What you do is copy this file into your active theme, then edit your copy as much as you want to.

The template file is heavily documented, so you can see what variables are set and what markup is being used. Just remember, do not edit the copy in the plugin folder as any updates will overwrite your changes. Copy the file into your theme first, then edit the copy there. The plugin will automatically detect the new file in the theme and load it instead.

The two year update notice is wrong, but not by much. The plugin was updated to fix a major security hole on 2/25/2012 (which was just over a year ago). However, the last version the plugin was explicitly tested with was version 3.3.2, so your mileage may vary with 3.5.1.

It would be a nice enhancement if the number of links displayed was configurable through the WordPress Dashboard.

That’s certainly one approach, but one I specifically avoided as not not needlessly clutter the Dashboard any more than it already is.

A better solution will be for me to rename the mimetype class in the next version, which I will do. Then you won’t need to worry about a thing 🙂

Thanks for the head’s up!

At the moment, no, but I’ll add this to my to-do list for potential future features.

https://github.com/ericmann/WP-Publication-Archive/issues/23