I have a post type archive with filtering in a sidebar and pagination at the bottom. One of my biggest problems is that I'll always lose any $_POST filtering whenever I click pagination as the page refreshes. I decided to circumvent this by storing my filtering variables in $_SESSION variables when the page posts, then use these along with pre_get_posts to get my filtered posts. The only thing in my $_SESSION is an array of filter variables which does persist through multiple pages ( doesn't get refreshed, pagination ) and cleared whenever a user visits something that is not the post_type_archive() or whenever a user submits the filtering form. It works and it works well as far as I know.

I showed my workaround to a friend and he thinks that using $_SESSIONS in this instance is a bad practice since it does store files in the server and on a on a high traffic site it could become cumbersome. He also mentions that locked down browsers may not handle sessions very well which I suppose is a possibility.

My question is, in this instance is using $_SESSIONS really a bad thing? From my understand they were made for this type of persistence. Are there any drawbacks to this type of design?

  • can you not just pass everything via GET? it would become a non-issue. – Milo Nov 11 '14 at 19:12
  • @Milo I could but I don't like the query strings it's outputting and would just like to run everything kind of "Behind the scenes" so the url always stays nice and pretty. Thus why I'm looking for alternatives and $_SESSIONs came to mind. – Howdy_McGee Nov 11 '14 at 19:30
  • @RyanLoremIpsum - That question has nothing to do with Sessions. I'm not asking how to achieve pagination I'm asking whether pagination with sessions is a good or bad practice and why. – Howdy_McGee Nov 11 '14 at 19:31
  • does it have to function without javascript? you could make your pagination links set a hidden field and submit your filter form. – Milo Nov 11 '14 at 19:32
  • @Milo I thought of that as an option, then just get whatever value is in the pagination link to pass to my form but ultimately decided to go with Sessions. After reading Ryans answer below though and after further research I'm realizing long sessions are generally bad. – Howdy_McGee Nov 11 '14 at 19:37

As far as their use within WordPress, there is no native method to use $_SESSION. This means it is entirely on you to mitigate any security issues this presents.

Other problems depend on how your session data is saved. One problem I'm aware of is when the allocated memory for memcache is reached, it will drop the least recently used objects to make room for new ones1. But then, this also shouldn't a problem for $_SESSION if you can allocate the appropriate amount of memory to support your site's level of traffic.

WordPress has an API for transients where the data is stored in the database unless a caching plugin is used (I believe this is ultimately determined by wp_using_ext_object_cache2). When stored in the database, the loss of least recently used data shouldn't be an issue with transients. There may be advantages and disadvantages to this (database vs fast memory), but I just wanted to demonstrate an example of WordPress's native stateless design solution to storing temporary data. This problem would have to be solved on the server side, outside of WordPress if it should arise while using $_SESSION.

There are performance advantages/disadvantages depending on whether session is saved in hard disk files, RAM, database or other. These relate more to how the server is set up than the use of $_SESSION in WordPress though, since WordPress is essentially blind to the use of $_SESSION.

WP Engine has posted a good outline for why they don't recommend the use of $_SESSION with WordPress3, which I've posted below. Some of these are more applicable to how the server is set up, but take a look and decide how they might affect your site and if you think $_SESSION is a good solution for you. As I said, WordPress is blind to the use of $_SESSION, it's not handled natively, which leaves this open to the broader scope debate of whether it should be used in your PHP code at all.

PHP Sessions
We do not currently recommend using $_SESSION variables at all. This is for a number of reasons:

  1. While WordPress itself supports the use of $_SESSION, WordPress is stateless and does not natively use $_SESSION. The proper way to work with WordPress is using cookies.

  2. There are a number of security concerns when using $_SESSION.:

    • Session Poisoning
      • The attacker first visits the victim’s page, and e.g. logs on. Attacker then uploads a PHP script to his account, and has it display context of $_SESSION (set by victim script).
      • Attacker determines which variable needs to be changed, uploads a script which sets this variable, executes it.
      • Attacker visits victim pages to see if anticipated exploit worked.
      • This attack only requires that victim and attacker share the same PHP server.
      • The attack is not dependent on victim and attacker having the same virtual hostname, as it is trivial for attacker to move the session identifier cookie from one cookie domain to another.
    • Session Fixation (on shared servers) For more information, see these two links:

    • Session ID hijacking can be a problem with PHP Websites. The PHP session tracking component uses a unique ID for each user’s session,
      but if this ID is known to another user, that person can hijack the
      user’s session and see information that should be confidential.
      Session ID hijacking cannot completely be prevented; you should know
      the risks so you can mitigate them. Depending on what plan you’re on
      with us, your site may run on a shared Web server. Be aware that any
      session variables can easily be viewed by any other users on the same server. Generally, the best way to mitigate this vulnerability by
      storing all sensitive data in a database record that’s keyed to the
      session ID rather than as a session variable. Non-sensitive data can
      be stored in cookies.

  3. For our customers who are set up on clusters, we would have to completely change how our load balancers work, just to make sure that $_SESSION variables were available between different servers.
| improve this answer | |

Short Answer, Yes, $_SESSION == 'bad thing'

Another possibility would be to disable the "built in" pagination and add ajax'd pagination. Then you can wire up your queries to respect the filters.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.