How is timing-out set? I lost info when writing something fairly long.

[BillyBoy0823]

I was working on my site, and I was writing a nice, long page and when I went to Save it, I lost it all. I was so ticked off. I could not hit "Back" to try to retrieve it either it. I had been logged out.

Lesson learned: Write it elsewhere and Paste.

The thing is, I looked in the Setting and the Session Lifetime was set to 24 hours.

What makes e107 time out, other than the Session_lifetime?

BTW< I did set the session time to 0, and it's still logging me out frequently.

[e107help[bot]]

Losing a long page like that is genuinely maddening, and your instinct to write-then-paste is the right reflex for now. @BillyBoy0823, the short answer is: Session Lifetime is the pref you can see, but it isn't the only clock running. There are three of them, and any one can fire before your 24 hours are up.

1. PHP's own session garbage collection. e107 reads your session_lifetime pref (default 86400 = 24h) and tries to push it into PHP with ini_set('session.gc_maxlifetime', ...):

• e107/e107_handlers/session_handler.php

  Line 223 in 6f38b7b

  $options['lifetime'] = (int) e107::getPref('session_lifetime', 86400);

• e107/e107_handlers/session_handler.php

  Line 234 in 6f38b7b

  ini_set('session.gc_maxlifetime', $options['lifetime']);

The catch is that many shared hosts either ignore that ini_set at runtime or keep everyone's session files in one shared directory. If a neighbouring site on the box has a low system-wide gc_maxlifetime (1440 seconds = 24 minutes is a very common default), its garbage collector can sweep up your idle session file long before e107's 24-hour intent kicks in. The page looks logged-in until you POST, then the server finds no session and bounces you. On your own XAMPP this is unlikely, but on live shared hosting it's the usual culprit.

2. The session cookie itself. The cookie that carries your session id has its own lifetime, also driven off that same pref. If the cookie expires (or the browser drops it), the session on disk may still exist but you no longer present the id to claim it.

3. The form security token. Every admin and content form carries a CSRF token. On current master that token's lifetime tracks the session lifetime rather than being a short separate window, so time alone usually isn't the issue here. What does bite on a long edit is the request fingerprint baked into the token: at the default security level it checks that your IP address still matches the one from when the form was rendered:

• e107/e107_handlers/csrf_handler.php

  Lines 234 to 238 in 6f38b7b

  	$validationRules = [
  	'RemoteAddr' => (e_SECURITY_LEVEL >= e_session::SECURITY_LEVEL_BALANCED),
  	'HttpVia' => (e_SECURITY_LEVEL >= e_session::SECURITY_LEVEL_HIGH),
  	'HttpXForwardedFor' => (e_SECURITY_LEVEL >= e_session::SECURITY_LEVEL_LOW),
  	'HttpUserAgent' => (e_SECURITY_LEVEL >= e_session::SECURITY_LEVEL_HIGH)

If your connection re-handshakes a new IP mid-edit (dynamic home IP renewing, a VPN reconnecting, hopping between WiFi and mobile), the save is rejected as a fingerprint mismatch and you land back at login even though the session technically lived. The longer the edit, the more chances for that to happen.

So your workaround is solid, and I'd add: keep the editor tab on a stable connection while drafting, and on shared hosting ask the host (or set in php.ini if you can) for a higher session.gc_maxlifetime.

For the longer term, I want to float something past @Deltik rather than promise it: a client-side safety net in the editor. A small periodic autosave of the editor contents into the browser's localStorage would mean that even if a token or session expiry rejects the POST, your text is still sitting in the browser to recover, with no server round-trip required. It's an open consideration, not a committed feature, but your story is exactly the case it would have saved.

[BillyBoy0823]

I am having more time-out problems. can you suggest a way, the site stops throwing errors if it times out. It comes back is USERNAME undefined and it is happening in a number of spots. Here's one of the errors I get.

Fatal error: Uncaught Error: Undefined constant "USERNAME" in S:\xampp\htdocs\e235\e107_plugins\tms\tms_postage_menu.php:33 Stack trace: #0 S:\xampp\htdocs\e235\e107_handlers\menu_class.php(730): include() #1 S:\xampp\htdocs\e235\e107_handlers\menu_class.php(612): e_menu->renderMenu('tms/', 'tms_postage_men...', '') #2 S:\xampp\htdocs\e235\e107_core\shortcodes\single\menu.php(34): e_menu->renderArea('2') #3 S:\xampp\htdocs\e235\e107_handlers\shortcode_handler.php(1312): menu_shortcode('2', '') #4 [internal function]: e_parse_shortcode->doCode(Array) #5 S:\xampp\htdocs\e235\e107_handlers\shortcode_handler.php(1020): preg_replace_callback('#\\{([A-Z][^\\x02...', Array, '{MENU=2}\r') #6 S:\xampp\htdocs\e235\e107_handlers\e_parse_class.php(850): e_parse_shortcode->parseCodes('{MENU=2}\r', true, NULL, NULL) #7 S:\xampp\htdocs\e235\e107_handlers\e107_class.php(401): e_parse->parseTemplate('{MENU=2}\r', true, NULL) #8 S:\xampp\htdocs\e235\e107_core\templates\footer_default.php(85): e107::renderLayout('<div style='tex...', Array) #9 S:\xampp\htdocs\e235\e107_plugins\news\news.php(2034): require_once('S:\\xampp\\htdocs...') #10 S:\xampp\htdocs\e235\news.php(23): require_once('S:\\xampp\\htdocs...') #11 {main} thrown in S:\xampp\htdocs\e235\e107_plugins\tms\tms_postage_menu.php on line 33

I am not sure how to solve this correctly.
I don't want to just give USERNAME a value, I don't think.
Not sure of a way to keep the sessions alive
need my AI buddy to help me :-)

[e107help[bot]]

@BillyBoy0823, happy to be the AI buddy on this one.

Here's the bit that'll make you groan: this fatal error and your timeout problem are the same problem wearing two hats. Once you see the link, it all falls into place.

Why it only happens sometimes

USERNAME is one of e107's logged-in-only constants. When you're logged in, core defines it here. But the moment your session lapses, e107 treats the next page view as a guest, and the guest branch just above it defines USER, GUEST, USERID, USEREMAIL… but not USERNAME. For a guest, that constant simply doesn't exist.

Now PHP 8 walks in. On PHP 7 and earlier, reading an undefined constant gave a warning and quietly resolved to the string "USERNAME", so old code limped along. PHP 8 turned that into a hard fatal Uncaught Error: Undefined constant. So:

• Logged in → USERNAME exists → page renders fine.
• Session timed out → you're a guest → USERNAME is gone → fatal.

Your footer menu ({MENU=2}) renders for everyone, guests included, so the second your session lapses, tms_postage_menu.php line 33 brings the whole page down with it. That's your "only sometimes."

The fix (and your instinct is right: don't hardcode it)

You're spot on not to just slap a value on USERNAME. Two clean options, depending on what line 33 actually does:

1. Modern accessor, what I'd reach for: e107::getUser()->getName(). Returns the username when logged in, a fallback you choose otherwise, and it never fatals:

   $name = e107::getUser()->getName();          // '' (well, false) for guests
   $name = e107::getUser()->getName(LAN_GUEST); // or give guests the label "Guest"

2. Minimal guard, if you want the tiniest diff:

   $name = defined('USERNAME') ? USERNAME : '';

Which one's correct depends on what tms_postage_menu.php does with USERNAME on and around line 33. Paste those few lines and I'll give you the exact swap. Fair warning: tms is a custom plugin, so it's outside what we officially support, but the root cause is core behaviour and the pattern is general, so I'm glad to help. And a heads-up: any unguarded USERNAME (or USERID, USERCLASS, USEREMAIL…) left in your migrated hacks will trip the same PHP 8 fatal the instant a guest hits it. Worth a quick grep across your custom files now, rather than meeting them one white-screen at a time.

The "logging me out frequently" bit, that one's self-inflicted, sorry

Setting Session Lifetime to 0 made it worse, not better. In e107, 0 doesn't mean "never expire." It feeds straight into ini_set('session.gc_maxlifetime', 0) here, which tells PHP your session is collectible immediately, so the garbage collector can sweep it on the very next request. It also switches off the sliding cookie-renewal that normally keeps you logged in (it early-returns when lifetime is 0). Put it back to a positive number (86400 for 24h, higher if you like), and the frequent logouts should calm right down.

So the running order I'd suggest:

1. Set Session Lifetime back to 86400 (or more) → fewer timeouts in the first place.
2. Guard USERNAME in the tms plugin (and any siblings) → so a timeout degrades gracefully instead of taking the page out.

Do those two and a lapsed session becomes a quiet "please log back in" instead of the white screen of doom.

[BillyBoy0823]

Thank you.
I set session.gc_maxlifetime to 7 days, so I no longer had to worry about leaving it on overnight.

I added this code to the one culprit:

if(!defined('USERNAME')){
    $message = "Your session has expired. Please log in again.";
    goto theeend;
}

The message comes from a plugin's menu that had restricted access, so I know they were not a guest.

But I have MANY menu's and pages, so I will have to go through them and see if I can get away with that code in each one.

I would think a better solution would be for e107 to define USERNAME as maybe an UNKNOWN class, so the UNKNOWN who times out gets a message "Please register or Sign in"..... or something along those lines.

Thanks for the pointers!

[BillyBoy0823]

An AHA moment. I am doing a NEW site, and updating my plugins. One of my older plugins, Chatbox II checks for a new message every 20 seconds, so I didn't have the problem. I think that refresh kept things alive when it would post "No new Messages". I could be wrong though.

It is not yet compatible with version 2+, and not installed. so that may be why I am just seeing the issue now. But that's only helping ME.

I think having the core set USERNAME to a something like an UNKNOWN class would be useful. Even more useful than setting it to GUEST in situations like I ran into with a CLASS I have timing out, and they were not a GUEST.

[Deltik]

Technically correct, @rica-carv, but the overhead is very negligible for the flexibility we gain. You could run e107::getUser()->get('user_name') a thousand times and the time taken is still not perceptible (but that specific call should not be done in a loop in your code anyway).

I'll have @e107help provide detailed benchmark statistics below:

[e107help[bot]]

Your instinct is sound, @rica-carv: reading the constant really is faster. I measured it in the project's Docker test harness so we can see by how much.

Setup. PHP 8.3.31 + MariaDB 10.11, opcache on / JIT off, bootstrapped in CLI so USERNAME is defined, with the current-user object seeded with an id so getName()/get() run their real logged-in path. Each warm figure is 60 samples of 100,000 reads, each read stored into a rotating buffer so the optimiser can't quietly delete it. Cold = the user-object singleton rebuilt from scratch each round. Full source and run commands are folded at the bottom.

Subsequent (warm) access, nanoseconds per single read:

read	min	p50	mean	p95	p99	sd
local variable (harness floor)	14.9	20.1	21.1	31.6	32.2	4.7
USERNAME (constant)	16.3	21.5	22.4	31.4	33.7	4.8
e107::getUser()->get('user_name')	235	296	314	422	505	68
e107::getUser()->getName()	675	801	847	1046	1106	124

Subtract the ~20 ns loop floor and the constant costs about 1 ns (a hashtable hit), get('user_name') about +276 ns, and getName() about +780 ns. So the accessor is dearer, by roughly 0.3 to 0.8 microseconds per read. getName() is the pricier of the two because it calls get('user_name') twice through its empty-name fallback (user_model.php#L165-L172); get('user_name') is the leaner call.

Run @Deltik's thought experiment: a thousand get('user_name') calls is 1000 × ~296 ns ≈ 0.3 ms, about the cost of a single indexed database query (more on that next), and nothing a visitor will ever feel.

First (cold) access, the part that actually costs something:

	min	p50	mean	p95	p99
build the user object + first getName()	0.35 ms	0.55 ms	0.90 ms	1.67 ms	6.39 ms
one indexed SELECT on the user row (for scale)	0.06 ms	0.30 ms	0.28 ms	0.49 ms	0.55 ms

Building e107::getUser() the first time is ~0.5 ms, and it sits right on top of a single user-row SELECT, because that is what it is underneath: a database load. That one build costs about 1,800x a warm get('user_name') call.

Here is the bit that settles the performance question: core builds that user object once per request during bootstrap, whether or not your code ever reads USERNAME. The benchmark confirmed it (current_user_prebuilt_by_boot=yes). By the time a menu or template runs, e107::getUser() is already warm, so swapping a bare USERNAME for the accessor adds none of the cold cost, only the ~0.3 µs warm delta.

And the accessor doesn't fatal for logged-out visitors, which a bare USERNAME does on PHP 8, the very crash that opened this thread, since USERNAME is only defined for logged-in users (class2.php#L1660-L1682). Paying a third of a microsecond so guests' pages don't white-screen is a trade worth making every time.

Caveat for the pedants, me very much included : this is the CLI SAPI; under php-fpm or mod_php the absolute numbers shift a little, but the relative shape holds. The opcache-off run was ~15 to 20% slower across the board, same proportions.

Environment, run commands, and full benchmark source

PHP 8.3.31   SAPI=cli   opcache.enable_cli=1   JIT=off
MariaDB 10.11 (tmpfs)
current_user_prebuilt_by_boot=yes
Seeded current user: isUser=true  get('user_name')='e107-cli'  getName()='e107-cli'  USERNAME='e107-cli'

Dropped in the docroot and run via the e107_tests/bin/e107-tests harness:

# production-representative (opcache on)
php -d opcache.enable_cli=1 -d opcache.jit=disable bench_e107help.php
# CLI default (opcache off)
php bench_e107help.php

<?php
/**
 * Benchmark: bare constant USERNAME vs e107::getUser()->get('user_name') / getName()
 */

$_E107['cli']                = true;
$_E107['debug']              = false;
$_E107['no_online']          = true;
$_E107['no_forceuserupdate'] = true;
$_E107['no_menus']           = true;
$_E107['allow_guest']        = true;
$_E107['no_maintenance']     = true;

require_once(realpath(__DIR__ . '/class2.php'));

if (!defined('USERNAME')) { fwrite(STDERR, "FATAL: USERNAME not defined after bootstrap\n"); exit(1); }

$bootBuilt = (e107::getRegistry('core/e107/current_user') !== null);
fwrite(STDERR, sprintf(
    "PHP %s  SAPI=%s  opcache.enable_cli=%s  jit=%s  current_user_prebuilt_by_boot=%s\n",
    PHP_VERSION, PHP_SAPI, ini_get('opcache.enable_cli') ?: '0',
    (function_exists('opcache_get_status') && ($st = @opcache_get_status(false)) && !empty($st['jit']['enabled'])) ? 'on' : 'off',
    $bootBuilt ? 'yes' : 'no'
));

// Seed the current-user object so getName()/get() run the real logged-in path.
$cu = e107::getUser();
$cu->set('user_id', 1);
$cu->set('user_name', 'e107-cli');
$cu->set('user_loginname', 'e107-cli');

function stats(array $xs) {
    sort($xs, SORT_NUMERIC);
    $n = count($xs);
    $mean = array_sum($xs) / $n;
    $var = 0.0;
    foreach ($xs as $x) { $d = $x - $mean; $var += $d * $d; }
    $sd = $n > 1 ? sqrt($var / ($n - 1)) : 0.0;
    $p = function ($q) use ($xs, $n) { return $xs[(int) round(($q / 100) * ($n - 1))]; };
    return ['n'=>$n,'min'=>$xs[0],'p50'=>$p(50),'mean'=>$mean,'p95'=>$p(95),'p99'=>$p(99),'max'=>$xs[$n-1],'sd'=>$sd];
}
function row($label, $s, $unit='ns/op') {
    printf("  %-28s n=%-3d  min=%9.2f  p50=%9.2f  mean=%9.2f  p95=%9.2f  p99=%9.2f  sd=%9.2f  (%s)\n",
        $label, $s['n'], $s['min'], $s['p50'], $s['mean'], $s['p95'], $s['p99'], $s['sd'], $unit);
}

// WARM: array-store harness defeats dead-code elimination; identical store
// machinery across ops, so the only difference is the source expression.
$K = 100000; $S = 60;
$nameVar = 'e107-cli'; $mask = 255; $buf = array_fill(0, 256, '');

$ops = [
    'baseline_local_var'          => function () use ($K, $mask, $nameVar, &$buf) { for ($i=0;$i<$K;$i++) { $buf[$i & $mask] = $nameVar; } },
    'const USERNAME'              => function () use ($K, $mask, &$buf)           { for ($i=0;$i<$K;$i++) { $buf[$i & $mask] = USERNAME; } },
    "getUser()->get('user_name')" => function () use ($K, $mask, &$buf)           { for ($i=0;$i<$K;$i++) { $buf[$i & $mask] = e107::getUser()->get('user_name'); } },
    'getUser()->getName()'        => function () use ($K, $mask, &$buf)           { for ($i=0;$i<$K;$i++) { $buf[$i & $mask] = e107::getUser()->getName(); } },
];

foreach ($ops as $fn) { $fn(); } // warmup

$samples = [];
foreach ($ops as $name => $fn) { $samples[$name] = []; }
for ($si = 0; $si < $S; $si++) {
    foreach ($ops as $name => $fn) {
        $t0 = hrtime(true); $fn(); $t1 = hrtime(true);
        $samples[$name][] = ($t1 - $t0) / $K;
    }
}
$sink = strlen(implode('', $buf));

echo "=== WARM: per-read cost (K={$K} reads/sample, S={$S} samples) ===\n";
foreach ($samples as $name => $xs) { row($name, stats($xs)); }

// COLD: first access = building the e_user singleton (constructor runs load()).
$R = 60; $coldBuild = [];
for ($r = 0; $r < $R; $r++) {
    e107::setRegistry('core/e107/current_user', null);
    $t0 = hrtime(true);
    $u = e107::getUser(); $x = $u->getName();
    $t1 = hrtime(true);
    $coldBuild[] = ($t1 - $t0);
}
echo "\n=== COLD: first getUser()->getName() (builds the user object), R={$R} ===\n";
row('cold build + first getName', stats($coldBuild));

$dbFetch = [];
for ($r = 0; $r < 40; $r++) {
    $t0 = hrtime(true);
    $row = e107::getDb()->retrieve('user', 'user_name', 'user_id=1');
    $t1 = hrtime(true);
    $dbFetch[] = ($t1 - $t0);
}
echo "\n  Context, one indexed user-row SELECT:\n";
row('SELECT user_name WHERE id=1', stats($dbFetch));

echo "\n[sink={$sink}]\n";

Cheers for prodding at it, @rica-carv. Better to know the real shape of the cost than to guess at it.

[rica-carv]

You could run e107::getUser()->get('user_name')

@Deltik Ok, i aknowledge that, but what if i want to retrieve username? Just like USERNAME constant does....
Should i use

$id = e107::getSession()->get('emulate');
e107::user($id)['user_name'];

???

[Deltik]

@rica-carv, it looks like you're referencing the user impersonation feature, which sets the USERNAME constant differently. That feature is currently a state management mess, and I do not recommend using it.

The usual way that USERNAME is set is in init_session(). For the current user, that $user is just e107::getUser(), so e107::getUser()->getName() holds exactly what USERNAME would have on a normal logged in page.

If you're looking for the username of a different user, consider e107::getSystemUser($id)->getName(), where $id is the ID of the user you want to look up. e107::user($id)['user_name'] is a less structured alternative to that.

[Deltik]

Note: I'm getting @e107help to rewrite the user permissions emulation feature. It's not impersonation as I erroneously called it. Track the progress in #5745.