Fixing Wordpress Session Cookie Paths

How to fix incorrect cookie path when developing systems to engage with Wordpress as a back-end.


Edited: 2021-09-02 10:04

Wordpress developers face a problem with session cookie paths when creating .php files outside of Wordpress that integrates features from Wordpress itself. For those not familiar with such setups, I can inform you that this type of setup is very useful when you just want to use specific features from Wordpress while creating your own UIs to engage with Wordpress as the "back-end".

The problem is that Wordpress session cookies only work for specific paths rather than the entire domain. This is actually a security feature that can prevent session information from getting into the wrong hands, but in reality this is perhaps not so useful, since you are probably the only one using your own domain name.

The problem might happen when you install Wordpress in a subfolder of your root, while creating your own "system" located on the bare domain that engages with Wordpress behind the scenes. The base path of your Wordpress installation then becomes: instead of — and this causes the cookies only to be valid beginning from the sub.

User not logged in on /

The problem is, the user will not be logged in on the root path, and whatever code you got laying around there will then not be able to use Wordpress features that require the user to be logged in.

If you call a function like is_user_logged_in from it will always return false, since the session cookie is only valid starting at: — luckily there is a very simple solution for this problem.

If you your composition root is located at, then simply place the following at the top of that script:

// Define some Wordpress variables
define('COOKIEPATH', '');
define('SITECOOKIEPATH', '');

// Load Wordpress specific features
require 'wordpress/wp-load.php';


Defining COOKIEPATH and SITECOOKIEPATH as empty will cause the cookies inside your own separate system to apply for the entire domain name rather than just for the subdirectory where Wordpress is installed.

If you rely on Wordpress build-in login page, then you should instead try to add this code in your wp-config.php file.

Alternatively you can just do like me and create your own login using wp_set_current_user and wp_set_auth_cookie, which avoids editing Wordpress own files.

Securing your Wordpress installation

In these types of setups, you might not want users to access the Wordpress back-end directly, since, in many cases, that is something you want only site-admins to be able to do.

One way to prevent this is by flat out denying non-admins access to /wordpress/.

You need to somehow perform a check like this:

$user = wp_get_current_user();
if (!user_can( $user, 'administrator' )) {
  echo 'You do not have the required permissions to access this area.';

This should be simple to implement. I would either create a plugin or try adding it in a child-theme; but you can also use the code snippets plugin, if you are not comfortable developing Wordpress plugins or child-themes.

See: The Right Way to Edit WordPress Themes

Tell us what you think:

  1. How to properly remove the title from a Wordpress post, and how to do it for specific post types.
  2. There is no function to select a post by slug name (post name), but we can create our own function to do it; find out how in this tutorial.
  3. How to properly customize Wordpress based website, where to add your own code, and how to override existing functionality.
  4. There can be several different reasons why jQuery might be undefined; maybe it is not yet loaded, or maybe a script is unloading it. In this tutorial I will explain some of the problems and solutions that I have come by when developing Wordpress websites.

More in: Wordpress Development