Cannot update existing e107 website #5904

Alex-e107nl · 2026-08-12T18:54:04Z

Alex-e107nl
Aug 12, 2026

Hi @e107help , github of today, tried to update existing site, used ftp all fine, but when i go to /e107_admin/db.php?mode=db_update i see:

<html><body>
<!--StartFragment-->
Update from 1.x to 2.0 |  
-- | --
Update from 2.x to 2.4.0 (git) |  
Update core database structure |  
Add new or missing core settings |  
Forum |  
Private Messenger |  
Youtube |  

<!--EndFragment-->
</body>
</html>

I can only press on the first button and i get a error 500 Unauthorized access! message.... i am the head admin.. hmmmmm

Should i do something extra that i do not know yet.... i have returned now to the backup so i can try it again...

@Alex-e107nl · 2026-08-12T19:26:47Z

e107help[bot]
Bot Aug 12, 2026

@Alex-e107nl thanks, the exact wording of that message narrows it down a lot.

Unauthorized access! as bare text with no admin styling comes from e107's CSRF gate in
class2.php, which runs before the update page renders anything. On today's master the
default for that gate changed: with the csrf_enforce preference unset, e107 asks your
browser where the request came from, via the Sec-Fetch-Site header, and does not look
at the form's security token at all.

e107/e107_handlers/session_handler.php

Line 167 in 022293b

const CSRF_CHECK_RECOMMENDED = self::CSRF_CHECK_SAME_SITE;

So the one thing I need from you: when you click Update, does your browser send that header?

F12, Network tab
Click the Update button
Click the e107_update.php request, then Headers → Request Headers
Look for Sec-Fetch-Site

Tell me whether it is there and what it says (same-origin, same-site, cross-site, or
missing entirely). That one line separates "your browser is older than the header",
"something in front of your server is eating it", and "the page and the form are on
different origins".

Quick cross-check while you are in there: log out and log back in. Logging in is a POST
through the same gate, so if that is refused the same way, it confirms the diagnosis.

To get moving before we sort this out properly, you can pin the older behaviour, which
accepts a security token or the browser check. Put this in a file at the top level of your
site, load it once in the browser, then delete it:

<?php
require_once('class2.php');
e107::getConfig()->set('csrf_enforce', 3)->save(false, true, false);
echo 'csrf_enforce set to 3';

Delete it straight after. While it sits there, anyone who finds it can run it.

After that the Update buttons should work, and the same setting is reachable from
Admin → Preferences → Site Preferences → Security & Protection, under "Proof that a request
came from this site". Pick "Security token or browser check".

You should not have to do any of this by hand, mind. e107 already handles the
"this browser cannot send the header" case for a fresh install and writes the compatible
setting for you. An existing site updated over FTP never runs that step, so it does not get
the same protection. I want to confirm which cause is yours before I put that in front of
Deltik as a core fix, so the header value above would really help.

0 replies

Alex-e107nl · 2026-08-12T19:56:27Z

Alex-e107nl
Aug 12, 2026
Author

@e107help

POST
/e107_admin/e107_update.php
Status
500
VersieHTTP/2
Overgebracht1,12 kB (grootte 0 B)
Referrer-beleidstrict-origin-when-cross-origin
Prioriteit aanvragenHighest
DNS-omzettingSysteem

cache-control
	no-store, no-cache, must-revalidate
content-length
	0
content-type
	text/html; charset=utf-8
date
	Wed, 12 Aug 2026 19:53:43 GMT
expires
	Thu, 19 Nov 1981 08:52:00 GMT
pragma
	no-cache
server
	Apache/2
vary
	User-Agent
X-Firefox-Spdy
	h2
	
Accept
	text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding
	gzip, deflate, br, zstd
Accept-Language
	nl,en-US;q=0.9,en;q=0.8
Connection
	keep-alive
Content-Length
	75
Content-Type
	application/x-www-form-urlencoded
Cookie
	e107_tzOffset=-120; PHPSESSID=tfk7ehm1j3caeu93025ovaklh2; e107_language=English; e107_debug_level=level%3D255
Host
	e107.nl
Origin
	https://e107.nl
Priority
	u=0, i
Referer
	/e107_admin/db.php?mode=db_update
Sec-Fetch-Dest
	document
Sec-Fetch-Mode
	navigate
Sec-Fetch-Site
	same-origin
Sec-Fetch-User
	?1
Sec-GPC
	1
TE
	trailers
Upgrade-Insecure-Requests
	1
User-Agent
	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:153.0) Gecko/20100101 Firefox/153.0

0 replies

@Alex-e107nl · 2026-08-12T20:13:24Z

e107help[bot]
Bot Aug 12, 2026

@Alex-e107nl that header settles it, and it settles it against me.

Sec-Fetch-Site: same-origin is exactly what the CSRF check wants to see. Your browser is
doing everything right and that request would have been let through. Do not run the
csrf_enforce snippet I gave you. It would not fix this and it would lower your protection
for nothing.

Two things in what you pasted rule the CSRF check out completely:

It answers 403. Yours is 500.
It sets Content-type: text/plain and writes Unauthorized access! into the body. Yours
came back content-type: text/html with content-length: 0, and Firefox agrees:
grootte 0 B. Not one byte was written.

e107/class2.php

Lines 605 to 621 in 022293b

    
           if($tokenOkay !== true) 
        
           { 
        
           	header('HTTP/1.1 403 Forbidden', true, 403); 
        
           	if(e_AJAX_REQUEST) 
        
           	{ 
        
           		// The envelope core's own AJAX endpoints already reject with. 
        
           		header('Content-type: application/json; charset=UTF-8'); 
        
           		echo json_encode(array('msg' => 'Unauthorized access!', 'error' => true)); 
        
           	} 
        
           	else 
        
           	{ 
        
           		header('Content-type: text/plain; charset=UTF-8'); 
        
           		echo 'Unauthorized access!'; 
        
           	} 
        
           	exit;

So PHP died before it printed anything, and display_errors is off on your server, which is
why you get a blank page and Apache reports 500. The real message exists, it is just sitting
in a log instead of on your screen.

Where to find it, quickest first:

e107_admin/error_log, and error_log in your site root. Plenty of hosts drop that file
right next to the script that died.
Your hosting panel. DirectAdmin and cPanel both have an Error Log page.
The PHP-FPM or Apache error log, if you have shell access.

If all of those are empty, make it print. Open e107_admin/e107_update.php and put these
two lines directly under the opening <?php on line 1:

@ini_set('display_errors', 1);
error_reporting(E_ALL);

Press the button again, copy whatever comes up, then take the two lines back out. That message
will name a file and a line number, and that is the whole answer.

Before you go log hunting though, one cheaper thing to rule out first: did that FTP upload
finish cleanly? The PHP 5.6 downgrade that landed on master on 11 August (#5898) rewrote over
350 files across the whole tree, including the bundled libraries under e107_handlers/vendor/.
An FTP session that quietly skips a file, or truncates one halfway, leaves you with a tree that
parses fine on one page and dies on the next. Upload the lot again, overwrite everything, and
try the button. If that clears it, we are done.

One thing I need to get straight. Your first post said "error 500 Unauthorized access!",
and those two cannot be the same response. When you press the button now, is the page blank,
or does it still say Unauthorized access!? If it still says it, there are two separate
failures in play here and I want the status code for that one as well.

Also handy: your PHP version.

The CSRF gap I went digging into is real and I will put it in front of Deltik regardless, it
just is not what bit you. Sorry for the detour.

2 replies

Alex-e107nl Aug 12, 2026
Author

@e107help PHP Version 8.3.33 Standard e107 with the dutch language but set to english, Firefox latest, changed setting --> Admin → Preferences → Site Preferences → Security & Protection, under "Proof that a request came from this site". Pick "Security token or browser check". Logged out, dropped cookies, logged in...

Done ftp 2 times now, had a backup restored in between that worked perfectly.

Clicking first update button and there's something strange... i already used a 2.33 version, Update from 1.x to 2.0? That cannot be the case.

Message from FF is De server op ******** heeft een fout teruggestuurd: 500 Internal Server Error

Error message:
[Wed Aug 12 22:25:08.779015 2026] [proxy_fcgi:error] [pid 2718313:tid 2718546] [remote ] AH01071: Got error 'PHP message: PHP Fatal error: Uncaught ValueError: PDO::query(): Argument #1 ($query) cannot be empty in /home//domains//private_html/e107_handlers/e_db_pdo_class.php:350\nStack trace:\n#0 /home//domains//private_html/e107_handlers/e_db_pdo_class.php(350): PDO->query()\n#1 /home//domains//private_html/e107_handlers/e_db_pdo_class.php(743): e_db_pdo->db_Query()\n#2 /home//domains//private_html/e107_handlers/db_verify_class.php(1282): e_db_pdo->execute()\n#3 /home//domains//private_html/e107_admin/update_routines.php(1422): db_verify->runFix()\n#4 /home//domains//private_html/e107_admin/update_routines.php(194): update_706_to_800()\n#5 /home//domains//private_html/e107_admin/update_routines.php(158): e107Update->updateCore()\n#6 /home//domains//private_html/e107_admin/e107_update.php(32): e107Update->__construct()\n#7 {main}\n thrown in /home//domains//private_html/...', referer: https:///e107_admin/db.php?mode=db_update

So... can you make anything of this, updating is a no go now... but the security measures must be applied for a live site...

e107help[bot] Bot Aug 12, 2026

@Alex-e107nl that log is the whole answer, thank you. This is a core bug, not your site, not
your host and not your security settings.

What actually happens

update_706_to_800() asks db_verify to repair the table structure. db_verify builds the SQL
for each fix and runs it. For one of your tables it built an empty statement and ran that.

PHP 8 refuses an empty query by throwing ValueError. e107 only catches PDOException around
that call, and ValueError is not one, so it escapes and kills the request. That is your 500.

The unguarded call:

e107/e107_handlers/db_verify_class.php

Line 1282 in 022293b

if(e107::getDb()->execute($query) !== false)

The catch that cannot see it:

e107/e107_handlers/e_db_pdo_class.php

Lines 346 to 360 in 022293b

    
           		} 
        
           		else 
        
           		{ 
        
           				/** @var PDO $rli */ 
        
           				$sQryRes = is_null($rli) ? $this->mySQLaccess->query($query) : $rli->query($query); 
        
           		} 
        
           	} 
        
           	catch(PDOException $ex) 
        
           	{ 
        
           		$sQryRes = false; 
        
           		$this->mySQLlastErrText = $ex->getMessage(); 
        
           		$this->mySQLlastErrNum = $ex->getCode(); 
        
           	} 
        
           }

On PHP 7 the same empty query just came back false and got logged as "Update Failed". On
PHP 8.3 it is fatal. That is why this has sat unnoticed.

Why the statement came out empty

It is a convert fix, the kind that corrects a table's storage engine or character set.
getFixQuery() starts with an empty string and only appends a clause when the live engine or
character set differs from the intended one:

e107/e107_handlers/db_verify_class.php

Lines 1195 to 1210 in 022293b

    
           case 'convert': 
        
           	$showCreateTable = $this->getSqlData($table); 
        
           	$currentSchema = $this->getSqlFileTables($showCreateTable); 
        
           	if($engine != $currentSchema['engine'][0]) 
        
           	{ 
        
           		$query .= $schema->tablePhysical($table) 
        
           			->addRaw(SqlFragment::raw("ENGINE=" . $engine . ";")) 
        
           			->getSQL(); 
        
           	} 
        
           	if($charset != $currentSchema['charset'][0]) 
        
           	{ 
        
           		$query .= $schema->tablePhysical($table) 
        
           			->addRaw(SqlFragment::raw("CONVERT TO CHARACTER SET " . $charset . ";")) 
        
           			->getSQL(); 
        
           	} 
        
           	break;

Both clauses were skipped, so it returned the empty string it started with. That can happen
because the two passes do not decide "intended" the same way. The comparison that queues the
fix works out what the table needs first and lets that narrow the answer:

e107/e107_handlers/db_verify_class.php

Lines 462 to 473 in 022293b

    
           // the state that could not be created in the first place. 
        
           $requirements = $this->deriveTableRequirements($fileData['field'], $fileData['index']); 
        
           $maybeEngine = isset($sqlDataArr['engine'][0]) ? $sqlDataArr['engine'][0] : 'INTERNAL_ERROR:ENGINE'; 
        
           $fileData['engine'] = $this->getIntendedStorageEngine($this->sqlFileTables[$selection]['engine'][$key], $requirements); 
        
           $sqlData['engine'] = $this->getCanonicalStorageEngine($maybeEngine); 
        
           $requirements['engine'] = $fileData['engine']; 
        
           $maybeCharset = isset($sqlDataArr['charset'][0]) ? $sqlDataArr['charset'][0] : 'INTERNAL_ERROR:CHARSET'; 
        
           $fileData['charset'] = $this->getIntendedCharset($this->sqlFileTables[$selection]['charset'][$key], $requirements); 
        
           $sqlData['charset'] = $sqlDataArr['charset'][0]; // check the actual charset. $this->getCanonicalCharset($maybeCharset);

The pass that builds the fix asks the same two questions without that context:

e107/e107_handlers/db_verify_class.php

Lines 1262 to 1269 in 022293b

    
           $query = $this->getFixQuery( 
        
           	$mode, 
        
           	$table, 
        
           	$field, 
        
           	$this->sqlFileTables[$j]['data'][$id], 
        
           	$this->getIntendedStorageEngine($this->sqlFileTables[$j]['engine'][$id]), 
        
           	$this->getIntendedCharset($this->sqlFileTables[$j]['charset'][$id]) 
        
           );

When those two disagree, the first says "this table is wrong" and the second says "nothing to
change", and you get an empty statement.

Getting you updated now

Open e107_handlers/db_verify_class.php and put this immediately above line 1282, the
if(e107::getDb()->execute($query) !== false) line, at the same indentation:

if(trim((string) $query) === '')
{
	continue;
}

An empty statement has nothing to execute, so skipping it is simply correct, and it leaves
every other fix in the run working normally. It will not leave the update stuck pending
either: the table-structure check does not re-arm the update row (update_routines.php:1417
is commented out).

Try the button again after that and it should go through. Tell me if it does not.

"Update from 1.x to 2.0? That cannot be the case"

You are right, and that row is mislabelled. The routine that retires obsolete preferences
lives inside update_706_to_800(), at line 1374, and that function starts at line 890. So
every time e107 retires a preference, that row re-arms on any 2.x site and announces itself as
a 1.x migration. jwt_secret joined the list a week ago (line 913). Nothing about your site is
being treated as 1.x. Deltik ran into exactly this on his own site a few days back.

Your security setting

You can put it back to "e107's recommended setting". Your browser does send
Sec-Fetch-Site (we proved that from your headers), so the default protects you properly and
my earlier advice to move off it was wrong. Your call, but there is no reason to stay on the
weaker option.

Two things that would help pin the root cause

So Deltik can fix why the statement is empty, not just stop it being fatal:

Admin → Database → Verify SQL Structure. Which table or tables does it flag, and what
does it say the storage engine and character set should be, versus what they are?
Your MySQL or MariaDB version.

I am writing this up for Deltik as a core bug now. Two separate defects, in fact: the empty
statement, and the fact that an unexpected database error takes the whole page down instead of
being reported. Thanks for digging the log out, it turned a guessing game into a five-minute
read.

Alex-e107nl · 2026-08-13T16:56:31Z

Alex-e107nl
Aug 13, 2026
Author

@e107help With ```
if(trim((string) $query) === '')
{
continue;
}

The first button update get passed, the next: Update from 2.x to 2.4.0 (git) also, but, the next: Update core database structure gives:
Success - Executed Update core database structure
System Debug
Update required in update_routines.php on line 626 (Database Tables require updating: admin_log, audit_log, banlist, comments, core, core_media, core_media_cat, cron, dblog, generic, admin_history, links, mail_recipients, mail_content, menus, news, news_category, online, page, page_chapters, plugin, rate, session, submitnews, tmp, upload, user, userclass_classes, user_extended, user_extended_struct, chatbox, download, download_category, download_mirror, download_requests, faqs, faqs_info, featurebox, featurebox_category, forum, forum_thread, forum_post, forum_track, gsitemap, hero, linkwords, newsfeed, private_msg, private_msg_block, polls, reference, rss)

Array
(
[admin_log] => Array
(
[_status] => 0
[_file] => core
)

[audit_log] => Array
    (
        [_status] => 0
        [_file] => core
    )

[banlist] => Array
    (
        [_status] => 0
        [_file] => core
    )

[comments] => Array
    (
        [_status] => 0
        [_file] => core
    )

[core] => Array
    (
        [_status] => 0
        [_file] => core
    )

<html><body>
<!--StartFragment--><h4>Debug Log</h4>

Message | Function | File | Line
-- | -- | -- | --
Session Save Method: db | e_session->setDefaultSystemConfig()() | /home/andrekoot/domains/e107.nl/private_html/e107_handlers/session_handler.php | 1503
Timezone: Europe/Amsterdam | init_session() | /home/andrekoot/domains/e107.nl/private_html/class2.php | 668
Retrieving default prefs from xml file | get_default_prefs() | /home/andrekoot/domains/e107.nl/private_html/e107_admin/update_routines.php | 511
Possible issue: Missing a Unique Tablerender ID. Use  $ns->setUniqueId() in the plugin script prior to setContent(). See  'source code' for more information. | e_render->setContent()() | /home/andrekoot/domains/e107.nl/private_html/e107_handlers/e_render_class.php | 391
Possible issue: Missing a Unique Tablerender ID. Use  $ns->setUniqueId() in the plugin script prior to setContent(). See  'source code' for more information. | e_render->setContent()() | /home/andrekoot/domains/e107.nl/private_html/e107_handlers/e_render_class.php | 391

<!--EndFragment-->
</body>
</html>

<html><body>
<!--StartFragment--><h3>PHP Errors:</h3><br>
			
Warning Undefined array key "core_media", Line 1240 of /home/********/domains/********/private_html/e107_handlers/db_verify_class.php
--
Warning Trying to access array offset on null, Line 1240 of /home/********/domains/********/private_html/e107_handlers/db_verify_class.php
Warning Undefined array key "core_media_cat", Line 1240 of /home/********/domains/********/private_html/e107_handlers/db_verify_class.php
Warning Trying to access array offset on null, Line 1240 of /home/********/domains/********/private_html/e107_handlers/db_verify_class.php
Warning Undefined array key "news", Line 1240 of /home/********/domains/e107.nl/private_html/e107_handlers/db_verify_class.php
Warning Trying to access array offset on null, Line 1240 of /home/********/domains/********/private_html/e107_handlers/db_verify_class.php
Warning Undefined array key "session", Line 1240 of /home/********/domains/********/private_html/e107_handlers/db_verify_class.php
Warning Trying to access array offset on null, Line 1240 of /home/********/domains/********/private_html/e107_handlers/db_verify_class.php

<!--EndFragment-->
</body>
</html>

And the update button stays yellow....

I am using 10.5.29-MariaDB ...

What can i do to get it done?

3 replies

e107help[bot] Bot Aug 13, 2026

@Alex-e107nl your log has caught a second one. Different bug, same file, and it is exactly why the button stays yellow.

Do this to get it done

No code editing needed for this one. Go to Admin → Database → Check database validity, tick the tables (there is a Check All at the top of that list) and submit. On the results page, press Check All and then Fix Selected Items. That screen builds its fix list a different way and does not go near the bug below, so the repairs actually run. Then come back to the update page and press the button again.

Worth pulling master again first, too. The four lines you added by hand are now in core properly (e0661bd3), so you can drop your edit and take the real one.

The first crash was mine

I moved that repair routine onto a different database method back in July, and the method it used before had been quietly swallowing the empty statement all along. Nothing was wrong with the change itself; it just took away the accident that was covering this hole. Sorry you were the one who fell in it.

Why "Success" leaves the button yellow

Those Undefined array key "core_media" warnings are the whole story.

db_verify keeps two lists: what is wrong with each table, and which SQL file each table was declared in. That second fact lives on the error list. When it compiles the fix-everything list it reads that name off the results list instead, where it does not exist, so it falls back to the table's own name:

e107/e107_handlers/db_verify_class.php

Line 636 in e0661bd

$file = varset($this->results[$tabs]['_file'], $tabs);

runFix() then takes that as a file name and looks it up. Nothing there, which is the warning you saw, and it moves on to the next table without a word:

e107/e107_handlers/db_verify_class.php

Line 1253 in e0661bd

$id = $this->getId($this->sqlFileTables[$j]['tables'], $table);

So it reports success having done nothing, the tables stay as they were, and the next check finds the same faults again. Yellow forever.

Only whole-table repairs are hit, meaning "create this missing table" and "convert this table's character set or storage engine". Field and index repairs carry their own file name and were always fine. And it has looked like it works for five years because a table that happens to share a name with the file declaring it comes out right by accident. core is one of those, and so is forum, and download. core_media, news and session have no such luck, which is exactly the set your warnings named.

If you would rather patch it

Same file, near the top of compileResults(). Find this line:

$file = varset($this->results[$tabs]['_file'], $tabs);

and change results to errors:

$file = varset($this->errors[$tabs]['_file'], $tabs);

That is the entire fix. It is filed as #5910 with the patch in #5911, both with your name on them. Merging is Deltik's call, not mine.

Two small things

Your Missing a Unique Tablerender ID debug lines are unrelated and harmless, they only appear because you have debug turned up.

And the security setting you switched to is a supported option and is causing none of this, so there is no hurry to move it back either way.

Tell me how the fix screen goes. If anything is still flagged after it, paste what it says and we will keep going.

Alex-e107nl Aug 14, 2026
Author

Okay, steps taken:

Restored backup;
First deleted all folders and files except for e107_media, e107_plugins, e107_system, and e107_themes; uploaded today's GitHub version via FTP;
Performed updates via e107_admin/db.php?mode=db_update;
Perfect for now, no error messages!

Thanks!

e107help[bot] Bot Aug 23, 2026

@Alex-e107nl good to hear it went through clean.

For anyone landing here later: both faults are fixed on master, e0661bd3 (#5906) for the empty statement behind the blank 500, and 8a466c09 (#5911) for the update that reported success while repairing nothing. The first also went to release/v2.3.x as #5907, but both landed after v2.3.11 was cut, so no tagged release carries either one yet; the second never affected that branch at all.

Uh oh!

Uh oh!

Cannot update existing e107 website #5904

Uh oh!

Uh oh!

Alex-e107nl Aug 12, 2026

Replies: 4 comments · 5 replies

Uh oh!

e107help[bot] Bot Aug 12, 2026

Uh oh!

Alex-e107nl Aug 12, 2026 Author

Uh oh!

e107help[bot] Bot Aug 12, 2026

Uh oh!

Alex-e107nl Aug 12, 2026 Author

Uh oh!

e107help[bot] Bot Aug 12, 2026

What actually happens

Why the statement came out empty

Getting you updated now

"Update from 1.x to 2.0? That cannot be the case"

Your security setting

Two things that would help pin the root cause

Uh oh!

Alex-e107nl Aug 13, 2026 Author

Uh oh!

e107help[bot] Bot Aug 13, 2026

Do this to get it done

The first crash was mine

Why "Success" leaves the button yellow

If you would rather patch it

Two small things

Uh oh!

Alex-e107nl Aug 14, 2026 Author

Uh oh!

e107help[bot] Bot Aug 23, 2026

Alex-e107nl
Aug 12, 2026

Replies: 4 comments 5 replies

e107help[bot]
Bot Aug 12, 2026

Alex-e107nl
Aug 12, 2026
Author

e107help[bot]
Bot Aug 12, 2026

Alex-e107nl Aug 12, 2026
Author

Alex-e107nl
Aug 13, 2026
Author

Alex-e107nl Aug 14, 2026
Author