Foxe Labs — Blog

How to automatically log out inactive users in WordPress

support@foxelabs.com (Joel James) — Fri, 04 Sep 2026 00:00:00 GMT

Walk away from a logged-in WordPress dashboard and nothing happens. Not after lunch, not overnight, not the next day. Out of the box, a WordPress login lasts 48 hours — and 14 days if the user ticked “Remember Me” — regardless of whether anyone touched the keyboard in between. There is no idle timeout, no “you’ve been signed out due to inactivity” screen, nothing.

For a personal blog, fine. For plenty of real sites, not fine:

A clinic, school, or office where shared and public computers are normal, and a walked-away-from dashboard is an open door.
A WooCommerce store where shop managers handle customer addresses and order history, and PCI-flavoured checklists ask for a 15-minute idle timeout on anything touching cardholder data.
A membership or LMS site where one login left open on a library machine is everyone’s problem.
Any site where an audit, an insurer, or a compliance framework asks the question “are inactive sessions terminated?” and the honest answer is “no, they last two weeks.”

This guide covers four ways to automatically log out inactive users on a WordPress website — from a one-line filter to a complete idle-timeout setup with a warning countdown — with honest pros and cons for each.

First, how WordPress decides you’re still logged in

When a user signs in, WordPress generates a session token, stores it in the wp_usermeta table under the session_tokens key, and puts a matching authentication cookie in the browser. Every request compares cookie to token. As long as both exist and the token hasn’t expired, the user is signed in.

The details that matter for auto logout:

Expiry is fixed at login time. The token gets an expiration timestamp when it’s created — 2 days, or 14 with “Remember Me” — and nothing about the user’s activity moves it. WordPress never asks “when were you last active?”, only “has your token expired yet?”
Closing the browser changes nothing. The token lives server-side. Reopen the browser within the cookie lifetime and the session resumes.
There is no inactivity concept anywhere in core. No last-activity timestamp, no idle check, no filter that fires when a user “goes quiet.”

So “auto logout after inactivity” is really two separate problems:

Shorten how long a login lasts overall (the session lifetime).
End a session that goes unused (the idle timeout) — which requires tracking activity yourself, because core doesn’t.

The methods below climb that ladder.

Method 1 — Shorten the session with auth_cookie_expiration

The auth_cookie_expiration filter controls how long the login cookie (and the matching server token) lasts. Drop this into a small companion plugin:

PHP

add_filter( 'auth_cookie_expiration', function ( $expiration, $user_id, $remember ) {
	// 4 hours for everyone, "Remember Me" or not.
	return 4 * HOUR_IN_SECONDS;
}, 10, 3 );

You can respect “Remember Me” while still tightening both values:

PHP

add_filter( 'auth_cookie_expiration', function ( $expiration, $user_id, $remember ) {
	return $remember ? DAY_IN_SECONDS : 2 * HOUR_IN_SECONDS;
}, 10, 3 );

New durations apply from each user’s next login — existing tokens keep the expiry they were minted with.

Pros

Core API, three lines, no dependencies.
Genuinely server-side. No JavaScript involved, nothing the user can bypass.
Solves the “two weeks is absurd” half of the problem outright.

Cons

It is not an idle timeout. A 4-hour session lasts 4 hours whether the user works the whole time or leaves immediately. Set it to 15 minutes and you’ll log out people mid-sentence; set it to 4 hours and an abandoned machine stays open for 4 hours.
No warning. The session just dies, and unsaved work in a half-written post dies with it.
One value for the whole site unless you write role-branching logic yourself.

Use this filter when the requirement is “logins shouldn’t last two weeks.” When the requirement is “log out inactive users,” keep reading.

Method 2 — A PHP snippet that tracks activity and ends stale sessions

A real idle timeout needs two pieces: record when each user was last active, and end the session once that timestamp is older than your limit. Here’s a minimal server-side version:

PHP

const MY_IDLE_TIMEOUT = 15 * MINUTE_IN_SECONDS;

// 1. Record activity (throttled to one write per minute).
add_action( 'init', function () {
	if ( ! is_user_logged_in() || wp_doing_ajax() || wp_doing_cron() ) {
		return;
	}

	$user_id = get_current_user_id();
	$last    = (int) get_user_meta( $user_id, 'my_last_active', true );

	if ( time() - $last > MINUTE_IN_SECONDS ) {
		update_user_meta( $user_id, 'my_last_active', time() );
	}
}, 1 );

// 2. Enforce the timeout before recording new activity.
add_action( 'init', function () {
	if ( ! is_user_logged_in() || wp_doing_ajax() || wp_doing_cron() ) {
		return;
	}

	$user_id = get_current_user_id();
	$last    = (int) get_user_meta( $user_id, 'my_last_active', true );

	if ( $last && ( time() - $last ) > MY_IDLE_TIMEOUT ) {
		wp_destroy_current_session();
		wp_clear_auth_cookie();
		wp_safe_redirect( wp_login_url() );
		exit;
	}
}, 0 );

Pros

An actual inactivity timeout, enforced server-side. Closing the tab or disabling JavaScript doesn’t help an attacker — the next request from that browser is dead.
You own the code and can tune every rule.

Cons

The logout only happens on the next request. An idle dashboard sits there looking signed-in until someone clicks; only then do they land on the login screen. Fixing that requires a JavaScript companion (Method 3).
No warning countdown, so long-form editors lose unsaved work.
The timestamp is per user, but sessions are per device — wp_destroy_current_session() only ends the requesting device, while activity on a phone keeps the timestamp fresh for an abandoned laptop too. Per-session tracking means storing timestamps per token, which is where the snippet stops being short.
Edge cases are on you: AJAX-heavy admin screens, the Heartbeat API firing from background tabs (count it as activity and an unattended dashboard never idles out), REST requests, multi-role users, WP-CLI.
It’s custom code the next developer has to discover and maintain.

This snippet is the honest core of every idle-logout plugin ever written. The gap between it and a finished tool is the last 80%: the warning, per-role rules, per-session accuracy, and the Heartbeat problem.

Method 3 — A JavaScript inactivity timer (and why it can’t stand alone)

The approach most tutorials reach for: a script that watches for mouse and keyboard events and redirects to the logout URL after X quiet minutes.

(function () {
	const IDLE_MS = 15 * 60 * 1000;
	let timer;

	function reset() {
		clearTimeout( timer );
		timer = setTimeout( () => {
			window.location.href = myVars.logoutUrl; // localised wp_logout_url() + nonce
		}, IDLE_MS );
	}

	[ 'mousemove', 'keydown', 'scroll', 'click', 'touchstart' ].forEach(
		( evt ) => document.addEventListener( evt, reset, { passive: true } )
	);

	reset();
})();

(The logout URL must be generated with wp_logout_url() server-side and passed via wp_localize_script, because it carries a nonce.)

Pros

The logout happens on time, visibly, right in front of the user — no waiting for a next request.
Easy to extend into a warning dialog: show a countdown at 14 minutes, redirect at 15.
The only method that can clean up the screen the moment time runs out.

Cons

It is not security — it’s UI. Close the tab, drop the laptop lid, kill JavaScript, or block the redirect, and the server-side session remains fully valid for its whole 2–14 day life. Anyone reopening that browser is still signed in.
Every tab runs its own timer. Typing in tab A while tab B’s timer expires logs you out of both, unless you sync activity across tabs (BroadcastChannel / localStorage events) — more code.
The logout nonce expires after 24 hours, so a day-old tab redirects to a “link has expired” screen instead of logging out.

The right mental model: the server decides, the browser performs. A JavaScript timer is the correct way to make the logout visible and punctual, and the wrong way to make it real. It needs Method 2 behind it — which means building and maintaining both halves, plus the cross-tab sync between them.

Method 4 — A per-role idle timeout from the admin (recommended)

Everything above converges on one design: server-side activity tracking and enforcement, a JavaScript layer for the countdown and punctual logout, throttled writes so tracking doesn’t hammer the database, and per-role rules because an administrator and a subscriber don’t warrant the same timeout. That’s precisely what the Auto Logout add-on for the free Loggedin plugin ships as a settings panel:

Idle timeout in minutes — from 1 minute up to 30 days, off by default so installing it never logs anyone out by surprise.
A warning countdown — a dialog appears before time runs out, with Stay signed in (renews the session) and Sign out now buttons. Ignore it and the logout happens at zero.
Per-role timeouts — an hour for admins, fifteen minutes for authors, nothing for subscribers. Unlisted roles keep the global value; when a user holds several roles with rules, the shortest timeout wins.
Custom session lengths — replaces WordPress’s hard-coded 2-day and 14-day durations with your own values (Method 1, without the code snippet).
Server-side enforcement — the idle check runs early on every authenticated request, so closing the tab or disabling JavaScript doesn’t extend a session. The browser script only makes the logout punctual and visible.
The edge cases handled — Heartbeat, AJAX, and REST requests are checked but never counted as activity (so a background admin tab can’t keep a session alive forever); WP-CLI and cron are exempt; activity in one tab keeps other tabs alive with no extra requests; and writes are throttled to roughly one small database write per user per quarter of the timeout.

It lives on the Users → Loggedin → Settings screen. Set the minutes, save, done.

How the methods compare

	auth_cookie_expiration	PHP snippet	JS timer	Auto Logout
True idle timeout (not just shorter sessions)	—	✓	looks like one	✓
Enforced server-side	✓	✓	—	✓
Logout happens on time, visibly	—	—	✓	✓
Warning countdown before logout	—	—	manual	✓
Per-role rules	manual	manual	manual	✓
Heartbeat/AJAX handled correctly	n/a	manual	—	✓
Non-technical owners can configure it	—	—	—	✓

The snippet methods are perfectly good for a developer who wants one specific behaviour and owns the codebase. The add-on is the same architecture with the last 80% finished — worth it the moment “log out idle users” is a requirement someone will audit rather than a weekend experiment.

Picking a sensible timeout

Numbers that hold up in practice:

5–15 minutes for privileged roles — administrators, shop managers, anyone who can see customer data. PCI DSS’s own idle-session guidance is 15 minutes, and shared-computer environments (clinics, schools, front desks) sit at the low end.
15–30 minutes for editorial roles, paired with a warning countdown so a slow writing session doesn’t eat a draft.
An hour or more, or no idle timeout at all, for subscribers and customers who are only reading — aggressive logouts here cost you logins-per-visit and goodwill for little security gain.
Session length (the Method 1 value) can stay comparatively generous — a day, say — once a real idle timeout exists, because the idle rule catches abandoned sessions long before the cookie expires.

And whatever you choose, roll it out with the warning enabled. The difference between “the site signed me out and lost my work” and “the site told me it was about to sign me out” is the difference between a support ticket and a shrug.

Wrapping up

WordPress ships with no inactivity logout — a login lasts 2 days, or 14 with “Remember Me,” no matter how long the browser sits untouched. You can shorten that lifetime with one auth_cookie_expiration filter, build a true idle timeout with a PHP activity tracker, and make it punctual with a JavaScript countdown — and now you know exactly which half of the problem each piece solves, and where the sharp edges are (Heartbeat, multi-tab sync, per-session tracking, expired nonces).

For a site where idle logout is a requirement rather than an experiment, the Auto Logout add-on packages that whole architecture — server-side enforcement, warning countdown, per-role timeouts, custom session lengths — into one settings panel on top of the free Loggedin plugin. And if you also want to see who’s signed in right now, or end a specific session yourself, that’s the Active Sessions add-on — covered in its own guide.

— JJ

Gold Scalpel: a pre-tuned XAUUSD scalper EA for MT5

support@foxelabs.com (Joel James) — Sun, 12 Jul 2026 00:00:00 GMT

Today we’re shipping Gold Scalpel, the first expert advisor out of Foxe Labs — a fully automated XAUUSD scalper EA for MetaTrader 5. It was built from a specific frustration: most gold scalper EAs on the market are either curve-fit demos that fall apart out of sample, or account-blowing grid bots that martingale their way to a margin call. We wanted the opposite — a disciplined gold scalper that treats capital preservation as the first job and edge as the second.

Here’s what it is, how it trades, and how to try it.

What is Gold Scalpel?

Gold Scalpel is a pre-tuned, fully automated MQL5 expert advisor for XAUUSD (gold) on MetaTrader 5. Rather than predicting direction, it identifies meaningful highs and lows around price, positions itself on both sides of the range, and commits only when price genuinely breaks through — never on a touch or a near-miss. The moment it’s in a trade, the focus switches to protection: the stop advances to breakeven as soon as the trade is onside, then trails the move.

It ships dialled in at the factory — the strategy’s internals are fixed, and you adjust only a handful of account-specific settings (about eight in total). There’s nothing to optimise, no dozens of parameters to guess at.

How the gold scalping strategy works

Every trade follows the same disciplined lifecycle:

Wait for a real move. No breakout, no trade — the EA stays patient.
Enter on the break. It’s already positioned on both sides, so it catches the genuine push when it comes.
Protect quickly. As soon as the trade is onside, the stop moves to breakeven, so a winner rarely turns back into a loser.
Trail the move. The stop follows price, locking in more of a clean run and exiting automatically when momentum fades.
Stand aside. A short cooldown after each trade avoids re-entering the same exhausted move.

That produces an asymmetric risk profile: most trades end at scratch or a small profit, a few ride a clean breakout for a real win, and large losses are rare because protection kicks in fast. You don’t need a high win rate — you need the average loss kept tiny, which is exactly what early breakeven is engineered to do. There’s no martingale, grid, or averaging into losers.

Risk control comes first

A scalper lives and dies by its losers, so Gold Scalpel runs several protections automatically:

Early breakeven & trailing — the primary safeguard that keeps the average loss small.
Position cap — bounds how many trades can be open at once.
Post-trade cooldown — a short pause that prevents over-trading one move.
Optional losing-streak cooldown — pause new entries after a run of losses, then resume automatically.
Automatic weekend pause — cancels resting orders and stops new trades into the weekend gap.
Maximum-lot ceiling — a hard cap on size, whatever the risk calc suggests.

Position sizing is percentage-of-equity: set your risk percentage and the EA computes the lot, capped by your maximum lot and snapped to your broker’s lot step. A live on-chart dashboard shows account, strategy state, and position counts, refreshed every second — even when the market is closed.

What the testing shows

Gold Scalpel’s performance is tracked forward in real time on a public MQL5 live signal. For a reference point, here’s a single real-tick backtest of the shipping build — one run, on one broker, over one period:

Test condition	Value
Symbol / platform	XAUUSD · MetaTrader 5
Period	~18 months (Jan 2025 – Jul 2026)
Modelling	Every tick based on real ticks (100%)
Risk per trade	2.0% (the conservative default)
Win rate	~78%
Profit factor	~3.9
Max drawdown	~6.8%
Total trades	319

At that 2% default risk, the ~18-month run compounded $1,000 into ~$15,232 — a +1,423% return. Because sizing is percentage-of-equity and compounding, that figure scales directly with your risk setting: raising the risk above the default produces a much larger return and a proportionally larger drawdown. Most traders should stay at 1–2% for a smoother curve like this one.

The high win rate is a by-product of early breakeven — many trades are protected before they can turn into losers — not a promise that most trades always win. The metrics that actually describe the edge are the risk-adjusted ones: win consistency, profit factor, and drawdown. Be sceptical of raw percentage returns, because sizing is percentage-of-equity and compounding, so the headline return scales directly with your risk setting — a bigger number at higher risk is the same strategy taking more risk, not a better one.

Trading involves risk. Every figure above is from a backtest, not live trading. Past performance — including real-tick backtests and the live signal — does not guarantee future results, and results vary with your broker, spread, period, and risk setting. Always validate on the free demo and a demo account before committing real capital, and only risk what you can afford to lose.

Who it’s for (and what you need)

Gold Scalpel is for traders who want a hands-off gold scalper with a few simple, safe settings rather than a parameter jungle — and who prefer many small, tightly-managed trades over a few big swings. Because it’s a scalper, spread is the single biggest factor in how it performs:

Platform: MetaTrader 5, on the XAUUSD symbol, any chart timeframe.
Account: hedging or netting, raw-spread or zero-spread strongly recommended.
Balance: runs from $100 in testing; $1,000+ recommended for live capital, paired with a conservative 1–2% risk.
VPS: recommended for 24/5 operation, not required.

How to get it

Gold Scalpel is a one-time $199 purchase on the MQL5 Market — lifetime updates, activation on up to 10 devices, and a free demo that runs in the MT5 Strategy Tester so you can backtest on your own gold history first.

Product details: Gold Scalpel on Foxe Labs
Buy or download the free demo: Gold Scalpel on the MQL5 Market
Setup guide: Getting started docs

Gold Scalpel is the first of several tools on our roadmap — a universal trading journal and a set of precision indicators are in the works. Test it honestly, size it sensibly, and let the discipline compound.

How to view active login sessions on a WordPress site

support@foxelabs.com (Joel James) — Sat, 27 Jun 2026 00:00:00 GMT

WordPress is famously bad at one thing: telling you who’s actually signed in right now. The Users screen lists every account that exists on the site — not the ones that are logged in. There’s no built-in “active sessions” panel, no per-device list, no last-seen column. For most sites this gap is invisible. For some it’s a real problem:

A membership site where one paid account is being shared across a family, a classroom, or a Discord server.
An LMS install where students log in from a coffee shop, forget to sign out, and a stolen laptop quietly keeps the seat warm for weeks.
A WooCommerce store where a customer just got refunded and you’d like to revoke their access without waiting for the session cookie to expire.
A staff portal where the security team needs to know which devices a leaver was still signed into when they handed in their notice.

If any of those sound familiar, this guide is for you. Below are four ways to view currently active login sessions on a WordPress website — from a raw database query through to a one-click admin tool — with honest pros and cons for each.

First, what’s a “session” in WordPress?

A WordPress session is created the moment a user successfully logs in. Internally it’s a session token — a random string stored against the user in the database. The token is also placed in an authentication cookie on the user’s browser. Every subsequent request hits the server, the cookie comes along, and WordPress matches the cookie against the stored token to keep the user signed in.

Two important facts that catch people out:

One session per browser, per device. A phone and a laptop count as two sessions. Two Chrome profiles on the same laptop count as two. An incognito window counts as a third.
Closing the tab does not end the session. The token lives on the server until the user explicitly clicks Log Out, the token expires (2 days by default, 14 days if “Remember Me” was ticked), or another login displaces it.

That’s why a stale browser tab a week later can still render as if the user is signed in — and why simply asking “is anyone logged in?” is a more useful question than it sounds.

WordPress stores these tokens in the wp_usermeta table under the meta key session_tokens. That’s the same row every method below reads from.

Method 1 — Run a SQL query against wp_usermeta

The most direct way to see active sessions is to ask the database. Open phpMyAdmin, Adminer, or your hosting control panel’s SQL console, and run:

SQL

SELECT u.ID, u.user_login, u.user_email, um.meta_value
FROM wp_users u
JOIN wp_usermeta um ON um.user_id = u.ID
WHERE um.meta_key = 'session_tokens';

You’ll get one row per user who has ever logged in and not been pruned. The meta_value column is a serialized PHP array of every token that user holds, keyed by token verifier. Each token entry looks like this once you unserialize it:

PHP

[
    'expiration' => 1719999999,   // unix timestamp
    'login'      => 1719399999,   // unix timestamp
    'ip'         => '203.0.113.4',
    'ua'         => 'Mozilla/5.0 …',
]

Pros

Works on every WordPress install. No plugins, no code.
Gives you the raw data — IP, user-agent, login time, expiry.

Cons

The meta_value is serialized PHP. Reading it in your head is unrealistic past a few rows.
Expired tokens stick around until the user logs in again, so the count is not the same as “currently active.” You have to filter expiration > NOW() yourself.
No search. No sort. No pagination.
Anyone running this needs database access — usually a developer, not the site owner.

This method is fine for a one-off diagnostic. It’s not a workflow.

Method 2 — Use WP-CLI

If you have shell access, WP-CLI gives you the same data in a much more readable form. To dump every user’s active sessions:

BASH

wp user list --field=ID | while read uid; do
  echo "User #$uid:"
  wp eval "
    \$tokens = get_user_meta( $uid, 'session_tokens', true );
    \$tokens = is_array( \$tokens ) ? \$tokens : array();
    foreach ( \$tokens as \$hash => \$t ) {
      if ( \$t['expiration'] > time() ) {
        echo '  ', date( 'Y-m-d H:i', \$t['login'] ),
             '  ', \$t['ip'],
             '  ', substr( \$t['ua'], 0, 60 ), \"\n\";
      }
    }
  "
done

You can also destroy any user’s sessions in one line:

BASH

wp user session destroy <user>

Pros

No serialization to read by eye — PHP does the work.
Scriptable. Easy to drop into a cron or a bash script.
The built-in wp user session destroy command is reliable.

Cons

Requires SSH access and WP-CLI installed.
No nice list view. The output is whatever your terminal can render.
Still no search across users by anything except ID.
Not something you can hand to a non-technical site owner.

WP-CLI is the right tool for one-off incident response if you’re already on the box. It’s still not a workflow.

Method 3 — A short PHP snippet using WP_Session_Tokens

WordPress exposes a clean PHP API for working with session tokens: the WP_Session_Tokens class. Drop the following into a small companion plugin (or your theme’s functions.php if you really must) to print a list of every user with at least one active session:

PHP

add_action( 'admin_notices', function () {
    if ( ! current_user_can( 'manage_options' ) ) {
        return;
    }

    $users = get_users( array( 'fields' => array( 'ID', 'user_login' ) ) );

    echo '<div class="notice notice-info"><p><strong>Active sessions:</strong></p><ul>';

    foreach ( $users as $u ) {
        $manager  = WP_Session_Tokens::get_instance( $u->ID );
        $sessions = $manager->get_all(); // array of currently-valid tokens

        if ( empty( $sessions ) ) {
            continue;
        }

        printf(
            '<li>%s — %d active session(s)</li>',
            esc_html( $u->user_login ),
            count( $sessions )
        );
    }

    echo '</ul></div>';
} );

Pros

Uses the official WP API. get_all() already filters out expired tokens, so the count is correct.
Compatible with custom session backends (Redis, Memcached) — anything that implements WP_Session_Tokens is honoured.
A great starting point if you want to build something custom.

Cons

Iterating every user is expensive past a few hundred. On a 50,000-user site this will time out.
It’s still just a list. No per-device drilldown, no IP, no sign-out button.
You’re maintaining custom code. The next person has to figure out what it does.

This one is closer to a real solution than the previous two, but you’re effectively writing the start of an admin tool you’ll never quite finish.

A quick word on plugins people try (that don’t do this)

A common piece of advice on forums is to install User Switching. It’s an excellent plugin — for switching between users — but it does not show you who is currently signed in. It’s worth mentioning because if you search for “see who’s logged in WordPress,” you’ll find it recommended, and you’ll waste an hour discovering it doesn’t do what you want.

Same goes for WP Activity Log, Stream, and other audit-logging plugins. They tell you who did things and when. They don’t tell you who is signed in right now.

Method 4 — A one-click admin tool (recommended)

If you’ve made it this far, the through-line is obvious: WordPress has every piece of information you need in the database, but no UI to look at it. The fastest way to close that gap is to add the missing UI.

The free Loggedin plugin already adds a concurrent-login limit and a Force Logout panel to the Users → Loggedin screen. Its Active Sessions add-on extends that screen with a dedicated Sessions tab showing every user with at least one live session, in one sortable, searchable list:

One row per user — display name, username, email, role, session count, last login time, last IP.
Sortable by username, email, session count, or last login.
Searchable across username, email, and display name.
Per-device drilldown — click any row to open a modal listing every device that user is signed in from, with IP, user-agent, sign-in time, and expiry side by side.
Single-session sign-out — revoke one device without disturbing the others (perfect for a stolen phone or an old tablet the user forgot about).
One-click sign-out-all — kill every session for a user, same as Loggedin’s Force Logout panel but without typing the username.
Bulk sign-out from the list — select multiple users and sign them all out in one action (handy after a credential leak or a refund batch).

It reads from the same WP_Session_Tokens storage every method above reads from, so the data is identical — there’s no new database table, no migration, no cron. Install it, open the tab, see your sessions.

Why this is the practical answer

	SQL query	WP-CLI	PHP snippet	Active Sessions
Non-technical owners can use it	—	—	—	✓
Auto-filters expired tokens	—	manual	✓	✓
Per-device view (IP, UA, expiry)	manual	manual	manual	✓
Sign someone out from the UI	—	partial	—	✓
Bulk operations	—	scripted	—	✓
Scales to thousands of users	—	—	—	✓

The other methods are perfectly valid for a one-off diagnostic or a developer who just needs to see what’s there. For anything you’re going to do more than once, having a real UI on top of the data is the difference between a workflow and a chore.

What about signing someone out once you’ve found them?

Whichever method you use to see sessions, ending one is straightforward. WordPress ships the API; you just have to call it.

One session, in code: WP_Session_Tokens::get_instance( $user_id )->destroy( $token_verifier );
All sessions for a user, in code: WP_Session_Tokens::get_instance( $user_id )->destroy_all();
All sessions for a user, in WP-CLI: wp user session destroy <user>
All sessions for a user, in the admin: the core Loggedin plugin’s Force Logout panel (free) accepts a user ID, email, or username and clears them in one click.
Per-device sign-out in the admin: the Active Sessions add-on’s per-user modal — the only built-in option here that lets you revoke a single device without disturbing the others.

A signed-out user won’t be notified, but the next page they try to load (or the next AJAX request from an already-open tab) will redirect them to wp-login. If you want that to happen the moment you click — without waiting for the user’s next click — pair Loggedin with its Real-time Logout add-on, which reloads the user’s open tabs the moment their session ends.

Wrapping up

WordPress doesn’t show you who is currently signed in by default, but the data has always been there in the wp_usermeta table. You can read it with SQL, with WP-CLI, or with a short PHP snippet — all three work, and any of them is fine for a quick one-off check.

For a workflow you’ll repeat — handling membership-share disputes, responding to a credential leak, kicking a refunded customer, auditing devices for a leaver — the answer is to add the missing UI rather than re-deriving it from raw data every time. That’s the gap the Active Sessions add-on fills, sitting on top of the free Loggedin plugin’s session controls.

Either way, you now know what a WordPress session actually is, where it lives, how to find it, and how to end it. That alone puts you ahead of most install owners.

— JJ

404 to 301 v4: a complete rewrite for custom redirects and 404 error management

support@foxelabs.com (Joel James) — Sat, 20 Jun 2026 00:00:00 GMT

After years of steady iteration, 404 to 301 v4 is here — rebuilt from the ground up with a modern React admin, a full custom redirect manager, a faster database layer, a REST API, WP-CLI support, and a growing ecosystem of official add-ons. If broken links and 404 errors are costing you SEO equity and visitors, this release gives you precise control over every URL on your site.

Why custom redirects and 404 errors matter for SEO

Every 404 error on your WordPress site is a missed opportunity. When a visitor — or a search engine crawler — lands on a broken URL, they hit a dead end. The link equity built up by that URL evaporates, the visitor leaves, and your bounce rate climbs.

Custom redirects — specifically 301 permanent redirects — pass the full SEO value of an old URL to the new one. They are essential after a site migration, a URL restructure, a domain change, or any redesign that moves pages around. Without them, you quietly bleed organic traffic every day.

But redirects alone are not the whole picture. You need to know which links are broken before you can fix them. That is where 404 logging comes in — and it is what has always made 404 to 301 different from a plain redirect plugin.

A redirect plugin fixes broken links. 404 to 301 finds them too.

What’s new in v4

Version 4 is a complete rewrite. The old admin has been replaced with a fast, modern React-powered interface. The database layer now uses dedicated, indexed tables for both logs and redirects, so every operation — matching a redirect, logging a 404, running a bulk action — is faster at scale.

Custom redirect manager with exact, prefix and regex matching
Per-redirect type, active/inactive toggle, hit counter and last-hit timestamp
Dedicated, indexed database tables for logs and redirects
Modern logs and redirects tables with search, filters, bulk actions and pagination
Per-log lifecycle status — open, ignored, or fixed
Email notifications with a configurable hit threshold
REST API at /wp-json/404-to-301/v1/
WP-CLI command set — wp 404-to-301 logs|redirects|settings
GDPR-friendly logging with IP masking and path exclusions
Official add-ons catalogue for free and premium extensions

Custom redirect manager

The headline feature in v4 is the built-in redirect manager. You can now create unlimited custom redirects directly inside 404 to 301 — no separate plugin needed.

Three matching modes

Every redirect rule uses one of three match types. Exact matching targets one specific URL path and nothing else. Prefix matching catches any URL that begins with the given path — useful after restructuring a section of your site, such as moving everything under /blog/ to /articles/. Regex matching gives you full regular expression support for complex, pattern-based rules, which is particularly powerful for developers managing large URL sets.

Per-redirect control

Each rule carries its own redirect type — 301, 302, 307 or any other valid HTTP status — so you are not locked into a single site-wide setting. Toggle any redirect active or inactive without deleting it. A hit counter and last-hit timestamp on every row show you which rules are actually being used, so you can confidently clean up stale rules over time.

Global 404 fallback

For any 404 that does not match a custom rule, you can set a global fallback destination — your homepage, a custom page, or any URL — with the redirect type of your choice. It is the safety net that catches everything you have not written an explicit rule for.

The matching engine uses a hashed, indexed database lookup so redirect resolution stays fast even with thousands of rules in place. Normal, healthy page loads are never touched — the plugin only does work when a 404 occurs.

404 error logging

Knowing which URLs are broken is just as important as redirecting them. The v4 logs table is a significant upgrade.

Every 404 is recorded with the requested URL, referrer, user agent, IP address and timestamp. Repeat hits to the same URL are deduplicated — one row per unique URL with a running hit count, so a popular broken link does not flood your table with thousands of identical rows.

Each log entry carries a lifecycle status — open, ignored, or fixed — so you can triage and track your broken link backlog over time. Filter by date range and status, search by URL or referrer, and bulk-update or delete entries in a single action. You can also turn any logged 404 into a custom redirect in a couple of clicks; the URL pre-fills the redirect form so there is no copy-pasting involved.

Email notifications

You do not need to log into the dashboard to know when broken links appear. The built-in email notification sends an alert when a 404 is recorded, with a configurable hit threshold so busy sites do not flood your inbox with every single occurrence. Set the threshold to five hits and you will only hear about URLs that have genuinely failed multiple times — a real problem worth acting on, not a one-off crawler hiccup.

REST API and WP-CLI

Version 4 is built for developers and modern WordPress workflows. A full REST API at /wp-json/404-to-301/v1/ covers every admin operation — querying and managing logs, creating and updating redirects, reading and writing settings. If you are building headless workflows, automating site maintenance, or feeding 404 data into external dashboards or reporting tools, the API gives you a clean interface to work against.

The complete CLI command set is available via wp 404-to-301, with subcommands for logs, redirects and settings. Multisite is fully supported — each site in the network maintains its own separate redirects, logs and settings.

Official add-ons

v4 ships with an official add-ons catalogue — free and premium extensions that integrate directly with the parent plugin. Each add-on does one thing well.

Free add-ons

Redirects Importer lets you bulk-import custom redirects from a CSV file, or migrate your existing rules directly from other redirect plugins — Redirection by John Godley and 301 Redirects by WebFactory are both supported. No manual re-entry, no copy-pasting.
Logs Exporter adds a one-click CSV export to the 404 Logs page. The export is filter-aware, so you can export just the rows matching your current search or date range — ready for Google Sheets, Excel, or your SEO team’s reports.

Premium add-ons

Logs Cleaner automatically prunes the 404 log table by age, by row count, or on a recurring schedule. Set it once and the database stays lean without any manual housekeeping — essential for high-traffic sites where the log table would otherwise grow without bound.
Email Reports delivers scheduled digests of your 404 activity — daily, weekly or monthly — straight to your inbox, each with an attached CSV of the underlying log rows. Stay on top of broken links without logging into the dashboard.
Telegram Alerts pushes a Telegram message the moment a 404 error is recorded. Alerts are dispatched in the background so visitors never wait on the Telegram API — you get real-time visibility into broken links with no front-end slowdown.

Get started

404 to 301 is free on WordPress.org. Install it from your plugins screen or download it directly. If you are upgrading from v3, back up your database first — v4 creates new dedicated tables and migrates your existing data on activation.

Download 404 to 301 free on WordPress.org →

From enemies to best friends

support@foxelabs.com (Joel James) — Wed, 23 Dec 2020 00:00:00 GMT

A disclaimer before we start: I write software for a living, not stories. I’ve never done this before, so bear with me if the seams show.

Okay. Once upon a time.

I’m Joel James, a software engineer of about seven years now. I’ve meant to write this down for most of them — I actually started it back in my second year of college — but like a lot of side projects, it sat at ninety percent finished while I told myself I’d get to it. This is me finally getting to it.

The beginning

I very nearly became a mechanical engineer. That was the plan. I showed up to enrol, the mechanical seats were already gone, and the only thing left was a B.Tech in Information Technology. So that’s the seat I took — less a decision than a leftover.

Up to that point, a computer was the thing I switched on during the Computer Period at school to open MS Paint. That was the full extent of it. Programming, when I finally met it, was not love at first sight. It was closer to a running feud — something I fought with every single day and mostly lost. Somewhere in there, though, the machine itself started to win me over, even while the code on it was still my sworn enemy.

The turning point that wasn’t

Late in my second year a relative handed me an old computer of my own, and that computer led me straight into hacking, which was where all my actual interest lived. Programming and I were still not on speaking terms. I finished my degree with the bare minimum marks and told myself, with real conviction, that I was done with code for good.

Real life had other ideas. Hacking, it turned out, was not going to pay the rent. With nowhere else to turn I looked back over my shoulder — and there was programming, still standing right where I’d left it. So I signed up for a three-month course, half expecting to hate it. Instead I had the best three months I’d had with a computer, mostly thanks to a teacher who was genuinely brilliant. That’s the stretch where I stopped fighting and decided, properly, to become a programmer.

Finding WordPress

I joined an IT company the moment the course ended. I was still a beginner, and a serious project landing on my desk was enough to make my hands shake — but that first company threw me straight at real, big work, which is exactly what I needed.

On the side I kept experimenting, and one of those experiments was a platform called WordPress. I got to lead a project on it, and I was hooked. I tried building a plugin, published it more or less to see what would happen, and a throwaway attempt pulled in far more people and far kinder words than I ever expected. That reaction lit something up. I started losing sleep to WordPress in the best way, building more plugins — the trail of them is on our software page if you’re curious.

The company itself didn’t have much WordPress work, so my day job ran on Laravel and Drupal instead. But WordPress never left my head, and I never let it go. It wasn’t all momentum, either. There was a low stretch I won’t sugarcoat — the kind where being let go plays on a loop in your head at 3 a.m. I’ve given that its own post rather than crowd it in here.

The turning point that actually was

By the third year I’d landed somewhere genuinely good: flexible hours, a team I liked, work I looked forward to. I could have happily stayed. But WordPress was still my thing, so I kept an eye on the companies working in it — and one day a WordPress developer role opened up at WPMU DEV (Incsub), a name I respected a lot.

I applied without taking it seriously, fully assuming nothing would come of it. Then a trial task turned into an offer letter, and the offer turned into the hardest call of my career: stay with the job I loved, or gamble on a harder, bigger one. The company was abroad, fully remote — and remote work was barely a thing where I lived back then. No office to walk into, no colleague to meet in person, everything through a screen. I took it anyway, on the plain belief that you don’t get anything worth having without risking something for it.

The end (the real one)

It worked. And it turned out to be about far more than getting to build WordPress for a living. It was the shape of the work — being able to do it from anywhere, around the people and the life that matter, without asking permission to step away when something came up. It put me in rooms (virtual ones) full of sharp people from all over the world. I’ve learned and un-learned more than I can count, often in lead roles, usually with the newest tools in hand. That’s the part I’m proudest of.

So that’s the story. Programming went from the enemy I dreaded to the thing my days are built around. These days I’m circling back to the projects I abandoned at ninety percent — this write-up being one of them — and picking them up one at a time.

If you’ve had a turn like this of your own, the kind where the thing you resisted becomes the thing you can’t imagine living without, I’d genuinely like to hear it.

Till the next one — take care.

— JJ

Partial string search in an array using PHP

support@foxelabs.com (Joel James) — Mon, 27 Jan 2020 00:00:00 GMT

I once needed something PHP doesn’t ship: a function that takes an array of strings and returns every element containing a given substring. in_array() only matches whole values, array_search() does the same and returns a key, and array_filter() gets you close but you still have to supply the matching logic. So for a WordPress project I wrote a tiny helper — and it turns out there are a couple of one-liners worth knowing too.

The helper: a loop around strpos

The most readable version is just a loop that keeps every string the keyword appears inside. strpos() returns the position of the first match, or false if there’s none — so the !== false check is doing the work:

PHP

/**
 * Partial-search an array of strings for a keyword.
 *
 * @param string[] $array   Array of strings to search.
 * @param string   $keyword Substring to look for.
 *
 * @return string[] Every element that contains the keyword.
 */
function array_partial_search( array $array, string $keyword ): array {
    $found = [];

    foreach ( $array as $string ) {
        if ( strpos( $string, $keyword ) !== false ) {
            $found[] = $string;
        }
    }

    return $found;
}

$fruits = [ 'apple', 'grapes', 'orange', 'pineapple' ];

$found = array_partial_search( $fruits, 'ap' );
// [ 'apple', 'grapes', 'pineapple' ]

The one thing that catches people out here is the !== false — with strpos you must use the strict operator. A match at position 0 (the keyword at the very start of the string, like 'ap' in 'apple') is a falsy 0, so a loose != false would silently drop it.

The modern one-liner: str_contains

PHP 8.0 added str_contains(), which returns a plain boolean and reads exactly like what you mean. Drop it into array_filter() and the helper collapses to a single line — no strict-comparison footgun, no loop:

PHP

$found = array_filter(
    $fruits,
    fn ( string $string ) => str_contains( $string, 'ap' )
);

One difference to keep in mind: array_filter() preserves the original keys, so you get [0 => 'apple', 1 => 'grapes', 3 => 'pineapple'] — note the missing 2. If you want a clean, re-indexed list, wrap it in array_values().

The regex one-liner: preg_grep

If you’re happy to reach for a regular expression, preg_grep() does the whole thing in one call — it returns every array element that matches a pattern:

PHP

$found = preg_grep( '/ap/', $fruits );

That’s the shortest option, but there’s a catch: your keyword is now a regex. If it ever contains characters like ., +, ( or /, they’ll be interpreted as pattern syntax rather than literal text. When the keyword is user input, escape it with preg_quote() first:

PHP

$keyword = '(ap';
$pattern = '/' . preg_quote( $keyword, '/' ) . '/';

$found = preg_grep( $pattern, $fruits );

Like array_filter(), preg_grep() preserves keys — array_values() again if you want them reset.

Case-insensitive search

All three approaches match case by default, so 'AP' wouldn’t find 'apple'. Making them case-insensitive is a small tweak per approach:

PHP

// strpos → stripos
stripos( $string, $keyword ) !== false;

// str_contains → lower-case both sides
str_contains( strtolower( $string ), strtolower( $keyword ) );

// preg_grep → the /i flag
preg_grep( '/ap/i', $fruits );

Which one to reach for

On PHP 8+, array_filter() with str_contains() is the clearest — it says what it does and sidesteps the !== false trap entirely.
preg_grep() is the most compact, and the natural choice when you’re matching a pattern rather than a fixed substring — just remember preg_quote() for untrusted input.
The explicit helper still earns its place when you’re on older PHP, or when you want an obvious, named function that the next person can read at a glance.

None of them is doing anything clever — that’s rather the point. It’s a gap small enough that PHP never filled it, and small enough that any of these one-liners closes it in a line.

— JJ

My first WordPress core contribution is live

support@foxelabs.com (Joel James) — Wed, 07 Dec 2016 00:00:00 GMT

WordPress 4.7 — named “Vaughan” in honour of the jazz vocalist Sarah “Sassy” Vaughan — shipped today. And for the first time, my name is in the list of core contributors. It’s a small patch, but seeing your name in a release that runs on millions of sites is a hard feeling to put into words.

The 4.7 release was led by Helen Hou-Sandí with release deputies Jeff Paul and Aaron Jorbin. There were 482 contributors this cycle — 205 of them for the first time, including me.

Giving back

Almost everything I build on belongs to open source. WordPress, Drupal, Laravel — I lean on them every day, for personal projects and professional work alike. So I try to give back to the community whenever I can. Over the years that’s mostly meant building and maintaining a handful of free WordPress plugins; I’d like to do more as I learn.

The contribution

One of the best ways to give back is to contribute to core itself, because a single fix there can help millions of websites at once. That thought alone was enough motivation to turn a private workaround into a real patch.

I hit the bug while importing content into a multisite install. After installing the WordPress Importer plugin, the AJAX response came back with a broken link. I fixed it for my own site first by editing a single core file — the kind of quick patch that’s easy to keep to yourself and move on.

Instead, I opened a ticket on WordPress Core Trac (#37943) with a patch. After a few rounds of feedback from other committers, a refined version landed in WordPress 4.7.

That’s the whole loop, and it’s smaller than people expect: notice something broken, fix it locally, then take the extra step of writing it up for everyone else.

If you want to start

You don’t need to be a core committer to help. A good first step is Get involved — the Make WordPress hub, where every team (core, docs, polyglots, support, design) lists ways to jump in. Plenty of contributions never touch PHP at all.

The contribution itself was tiny. The lesson wasn’t: the projects we all depend on are only as healthy as the people willing to file the ticket instead of quietly patching their own copy. Thanks to WordPress and the community around it for making that first step so welcoming.

— JJ

What the 404 to 301 tracking incident taught me about plugin security

support@foxelabs.com (Joel James) — Wed, 17 Aug 2016 00:00:00 GMT

Back in 2016, 404 to 301 — my most-used plugin, then on 100,000+ sites — was flagged publicly for shipping a feature that misbehaved. It was one of the hardest weeks of my open-source life, and also one of the most instructive. I’ve kept the original apology on my old blog, but what’s actually worth carrying forward isn’t the drama — it’s the engineering lessons. So here’s the level-headed version, years later.

What actually happened

The plugin had an optional usage-tracking feature. It came out of a partnership: another developer wanted anonymous usage statistics (visitor IP and user-agent), and in exchange the plugin would display a small third-party “credit” text link. On install, users were asked to opt in.

Two things made that a bad design, and I own both:

The credit links were remote content. The text to display was fetched from the partner’s server, so what actually got served wasn’t fixed in my plugin’s code — it could change at any time, without a new plugin release for anyone to review.
That’s exactly what happened. The partner later changed their server to return cloaked ad links — injected near the top of the page, but only when a search-engine crawler requested it, so a normal visitor never saw them. That’s cloaking, and it can damage a site’s search rankings. A security vendor found it, published a report, and a wave of negative reviews followed.

I removed the tracking feature completely and shipped an update within hours of learning about it. The WordPress.org plugins team reviewed the situation, and the takeaway they reinforced has stuck with me: third-party ads must be opt-in and must never track users.

The three mistakes

Stripped of everything else, I made three concrete engineering errors:

I shared commit access without keeping control. The partner’s code went out under my account, and I treated their contributions with less scrutiny than my own.
I misread the guidelines on remote content. I thought a small credit link was harmless. Loading anything from a third-party server into someone else’s site is not harmless — it’s a decision with security and privacy weight.
I didn’t keep verifying the remote response. I tested it once, saw the small credit text, and trusted it. A response you fetch from someone else’s server is not a thing you verify once; it’s a thing that can change the day after you look away.

Why this is a supply-chain problem, not a one-off

The reason this is worth retelling is that it’s the same shape as the supply-chain attacks that keep hitting the ecosystem: code or content you don’t fully control, running inside software people trust. It doesn’t matter whether it arrives as an npm dependency, a “partner” SDK, or a friendly credit link — the moment a remote party can change what your software does after review, you’ve handed them your users’ trust.

The uncomfortable part is that the popularity of the plugin made it more attractive as a vector, not less. Reach is exactly what makes a plugin a target.

What I do differently now

No shared commit access without review. Contributions get read and understood before they ship, no matter who they’re from.
Remote content is an attack surface. If a feature loads anything from an external server, it gets treated as untrusted — verified, constrained, and monitored, not tested once and forgotten.
Opt-in, and no tracking. Anything touching a user’s visitors is opt-in by default and collects nothing that identifies them. When in doubt, it doesn’t ship.
Fix first, explain fully. Remove the offending code immediately, then be transparent about what happened. People are remarkably forgiving of an honest, fast response.

404 to 301 has carried no third-party tracking or remote ad code since that 2016 update, and it never will again. The incident was avoidable, and owning that is the point — but the reason to write it down is so the next developer weighing a too-good partnership offer recognises the shape of it before signing on.

— JJ

Countdown redirect using JavaScript

support@foxelabs.com (Joel James) — Sat, 05 Mar 2016 00:00:00 GMT

Sometimes you want a redirect that pauses for a few seconds — showing a “redirecting in 3… 2… 1…” message — before sending the visitor on. It’s the pattern you see on “thank you” pages, interstitials, and link shorteners: give the reader a moment to notice a message, then move them along.

The idea is simple: show the remaining seconds, count down once per second, and navigate away when the timer hits zero. Here’s a clean, modern version.

The markup

HTML

<p>
  Redirecting in <span id="countdown" aria-live="polite">10</span> seconds.
  <a id="go-now" href="https://example.com">Go now</a>.
</p>

Two small things earn their keep here. The aria-live="polite" attribute means screen readers announce each new number as it changes, and the “Go now” link is a plain anchor — so the redirect still works if JavaScript never runs, and impatient visitors can skip the wait.

The JavaScript

const target = 'https://example.com';
const el = document.getElementById('countdown');
let seconds = Number(el.textContent); // start from whatever the HTML shows

const timer = setInterval(() => {
  seconds -= 1;

  if (seconds <= 0) {
    clearInterval(timer);
    window.location.assign(target);
  } else {
    el.textContent = seconds;
  }
}, 1000);

That’s the whole thing. setInterval fires the callback once a second; we drop the counter, update the visible number, and when it reaches zero we clear the interval and navigate. Reading the starting value from the HTML means the number you write in the markup is the single source of truth — change 10 in one place and everything follows.

Avoid the classic setTimeout mistake

Older examples (including the one this post replaces) used a string argument:

// Don't do this — the string is evaluated like eval().
window.setTimeout("countdown()", 1000);

Passing a string to setTimeout or setInterval makes the browser evaluate it as code, which is slower, breaks under a Content Security Policy, and hides bugs from your tooling. Always pass a function reference instead, as in the example above.

assign vs replace

window.location.assign(target) keeps the countdown page in the browser history, so pressing Back returns to it. For an interstitial you’d rather users not land back on, use replace():

window.location.replace(target); // Back skips the countdown page

A no-JavaScript fallback

If you don’t need a live counter at all, HTML can do a timed redirect on its own with a meta refresh — handy as a fallback, or for pages where you can’t run scripts:

HTML

<meta http-equiv="refresh" content="10; url=https://example.com" />

It can’t show the seconds ticking, but it fires even with JavaScript disabled. Pair it with the script above and you’ve covered both cases.

That’s all it takes — a visible number, a one-second tick, and a navigation call at zero. Keep coding.

— JJ

Laravel bail: stop validation on the first failure

support@foxelabs.com (Joel James) — Mon, 01 Feb 2016 00:00:00 GMT

Laravel ships with a deep set of validation rules, and most of the time they’re all you need. But the docs don’t surface everything — now and then the feature you want is sitting right there in the source, just undocumented. This is the story of one of those, and how it ended up in the framework.

The bug my tests didn’t catch

I had a user_id field with what looked like sensible rules: it had to be present, an integer, and unique in the users table.

PHP

$this->validate($request, [
    'user_id' => 'required|integer|unique:users,user_id',
]);

It worked in my own testing. Then QA typed letters into the field and got a database error instead of a clean validation message.

Here’s why. By default Laravel runs every rule on an attribute and collects all the failures. So with a non-integer value, required passed, integer failed — and unique still ran anyway, firing a SELECT against a column the schema only allows integers in. The query blew up before validation could return a tidy message. My first instinct was a custom rule to work around it.

The one-word fix

What I actually wanted was for validation to stop at the first failure on that attribute, so a broken value never reaches the unique query. At the time the clean way to do that wasn’t in the documentation — so I built it and opened a pull request against Laravel. It was merged, and shipped in Laravel 5.2 as the bail rule:

PHP

$this->validate($request, [
    'user_id' => 'bail|required|integer|unique:users,user_id',
]);

With bail first, the moment required or integer fails, Laravel stops and never runs unique — no stray query, no database error. Two things to remember:

Order matters. Rules run top to bottom, so put the cheap, structural checks (required, integer) before the ones that hit the database (unique, exists).
bail is per-attribute. It only short-circuits the field it’s on; other fields still validate normally.

Still true today

Ten years on, bail is still the idiomatic answer, and it reads even better with the array syntax most Laravel code uses now:

PHP

use Illuminate\Validation\Rule;

$request->validate([
    'user_id' => ['bail', 'required', 'integer', Rule::unique('users', 'user_id')],
]);

That’s the whole trick — one small rule that turns a leaky “run everything” pass into a clean “stop when it breaks” one. It’s also a nice reminder that the frameworks we lean on every day are just code, and open enough to fix when they come up short.

Love Laravel. Keep coding.

— JJ