Install issue with upgrade OR new install

[BillyBoy0823]

To preface this, I am working on 'test' site using xampp locally before I put it live.

I first tried to Upgrade a site I am working on to 2.3.5, but It would not open. I got the message;

"Site Configuration Issue Detected. Please contact your webmaster."

Couldn't figure it out, so I Did a FULL install, moved everything over, and once I got to setting My Site URL, I got the message again!

I am using Localhost, and other NON https addresses, and it fails.

I am having a hard time getting a fake cert to work on my windows setup.

What is a quick work-around so I can get back to work.

TIA!

[e107help[bot]]

Hey @BillyBoy0823, the message you're hitting is the v2.3.5 host-mismatch killswitch. The HTTPS angle is a red herring; you can park the fake-cert side quest.

You're the second person it's caught this week. @Digioso hit it on a different host pattern in #5627, where the broader UX problem (this die() line is genuinely unhelpful in the way it landed for both of you) is being spec'd. Worth a read for the wider context, but here's the XAMPP-flavoured version of the workaround.

What's actually happening

The kill lives at e107_handlers/e107_class.php:5537 in v2.3.5. It compares the host portion of your stored Site URL pref against the Host header the browser actually sent. If they don't match (and the visited host isn't a subdomain of the configured one), the page dies before any other code runs. Same kill regardless of http vs https, so getting a fake cert wouldn't change anything.

XAMPP traps that get you here on a perfectly innocent dev box:

1. localhost vs 127.0.0.1 vs your computer name. Stored one, visited the other.
2. Custom Apache port. parse_url('http://localhost:8080/', PHP_URL_HOST) strips the port and returns localhost, but $_SERVER['HTTP_HOST'] keeps it (localhost:8080). Strict !==, doesn't match, dies. So any non-80/443 port currently trips this unconditionally, even if you typed the URL in identically.
3. http in the pref but visiting via https through a reverse proxy that rewrites Host. Less likely on XAMPP, mentioning it for completeness.

@Deltik, the second one is a real bug rather than a config trap on the user's side. A port-strip on HTTP_HOST (companion to the www.-strip planned for Layer 1 in #5627) would absorb the XAMPP/MAMP/non-default-port cohort cleanly in v2.3.6.

The clean local-dev fix

The killswitch is a no-op when siteurl has no host part. The condition short-circuits on !empty($configured_host), since parse_url('/', PHP_URL_HOST) is null. The install default is exactly that, set at install.php:1829 as e_HTTP, which is a path-only value like / or /yourdir/.

For a XAMPP test box, leaving siteurl at / is actually the right answer. SITEURL then gets derived from HTTP_HOST per request, so localhost, 127.0.0.1, your machine's hostname, port 8080, all of it works without further config. When you ship to the real domain, you set the production URL in admin then, on the live host.

Since you've already bricked the wizard by setting a full URL, you'll need to revert via DB (the admin form's HTML5 pattern="^http.*" won't let you save / from the UI, only an external client).

Open e107_config.php, note your $mySQLprefix (default e107_). Then in phpMyAdmin or any client:

SELECT e107_value FROM e107_core WHERE e107_name = 'SitePrefs';

Find siteurl in the result. Two formats exist in the wild:

• Modern (var_export): 'siteurl' => 'http://something/',
• Legacy (PHP serialize, pre-2008 installs only): s:NN:"http://something/"; where NN is the byte length

For the modern format:

UPDATE e107_core
SET e107_value = REPLACE(
    e107_value,
    "'siteurl' => '<whatever's there now>'",
    "'siteurl' => '/'"
)
WHERE e107_name = 'SitePrefs';

For the legacy s:NN:"..." format, the NN prefix has to be the byte length of the new value exactly:

UPDATE e107_core
SET e107_value = REPLACE(
    e107_value,
    's:<oldlen>:"<whatever>";',
    's:1:"/";'
)
WHERE e107_name = 'SitePrefs';

Save, reload, and the site should come back up at whatever hostname you visit. Don't re-edit Site URL via admin while you're still on the test box, or you'll just brick yourself again.

Heads-up on the upstream side

The current die() is a security backstop from GHSA-7pmw-jwvr-cq2x (Host Header Injection in password reset), so it's not going anywhere. But the way it lands is being made considerably less hostile in v2.3.6: a real 503 instead of a 200 with no recovery hint, a log line that actually fires (right now the error_log() below the die() is unreachable, which is why even e_DEBUG = true got @Digioso nothing), and a www.-strip so a www.example.com/example.com mismatch passes silently. Full spec is on #5627.

Shout if / doesn't bring it back.

[Deltik]

Bleh, I hadn't considered the port number use case. I'm going to work on getting a v2.3.6 out sooner, because so many users are having difficulty with the original fix for CVE-2026-43935.

[BillyBoy0823]

I made a big mess.

I wrote a site in 2005 with e107 and a lot of hacks, and it is STILL running. It's too old to do anything with now, so I updated and basically re-worked old plugins to work with 2xx. I was 95% there and surprised at how I was able to get my ole plugins working again considering the e107 code looks so foreign to me now (I am a straight-line hacker at best).

I was so close, and then saw the NEW update, so I installed it. I didn't see when lock-out happened when I did the upgrade, so I installed the full version. I copied over all my work, reset all my values throughout, then I set the site url to localhost, and it was back with the "Site Configuration Issue Detected. Please contact your webmaster." message. So, at that point I knew about where to look. I did use phpmyAdmin to go into the core prefs to try and change the site url. I tried localhost, 127.0.0.1, domain names with http:, ones with https:, as well as leaving it blank. Nothing worked.

I tried looking at the e107 code, to see if I could figure a bypass, but I'm just not that smart.

That's when I figured it might be related to needing SSL, which took me down a long, dark path lol.

I could get Cert's installed on my computer, but I still couldn't get a site to work with https: on my system with localhost or 127.0.0.1. I also saw, each browser had different issues with ssl, and solutions. I tried many. I ended up messing up xampp and having to backtrack and reverse all the hacks I did to that. Plus reset changes I did to my browsers which may have made them insecure.

THIS is when I finally decided to bug you guys. Two days of cluelessness for me.

I tried the db REPLACE you sent in post 2, but I could not get it to work. I also tried to go in with phpMyAdmin again and just change it myself. I did, but I am still locked out. :/

Any other suggestions?

I am probably going to just install full again and avoid saving those admin prefs that contain the url so I can move on.

Thanks for getting back so fast though!

I love e107, I tried many CMS's back in the day and it was the easiest for me to understand and adapt to my needs. So thanks for the work you all put into it!

[Deltik]

SitePrefs are cached in a file at e107_system/*/cache/content/S_Config_core.cache.php. Try deleting that file?

I'll get e107help to give you a detailed explanation in this thread.

[e107help[bot]]

@BillyBoy0823, oh hell, I owe you an apology. Two days of you fighting this and I missed the most likely reason my fix didn't land: e107 has a pref cache sitting in front of the DB row. Direct DB edits don't take effect until that cache is cleared, with a 24-hour TTL by default.

e107_handlers/pref_class.php:467-501 is the loader. On every request it checks e107::getCache()->retrieve_sys('Config_core', ...) first. If that returns anything non-empty, it uses the cache and never touches the e107_core table. So every value you wrote via phpMyAdmin (localhost, 127.0.0.1, http, https, blank) made it into the DB and was then immediately ignored on the next page load, because the cache still held the original bad value from your first admin Save.

The actual recovery sequence

1. Edit siteurl in SitePrefs to / (or empty; either works, since both make parse_url(..., PHP_URL_HOST) return null and skip the killswitch).
2. Delete the pref cache file from your XAMPP filesystem: e107_system/cache/content/S_Config_core.cache.php. That's the default path; if your install has a custom SYSTEM_DIRECTORY configured, it's the cache/content/ subfolder under whatever that is.
3. Reload the site.

On reload, prefs load from the DB (cache is gone), the killswitch sees no host in siteurl, no die(), page comes up. The cache then re-populates with the corrected value. No reinstall needed; your migrated work stays put.

If you'd rather nuke broadly than be surgical, deleting everything in e107_system/cache/content/ works the same way and rebuilds on next request.

Why post one missed this

The SQL I gave you was correct for the DB row, but I went straight from "edit the DB" to "reload" without surfacing the cache hop in between. The cache layer is invisible from the admin UI (which clears its own caches on Save), so it only shows up as a problem when you bypass admin and edit the DB directly. Which is exactly what you were doing.

Side note

That 2005 e107 site you've been keeping alive is genuinely impressive. And good news from @Deltik upthread on the v2.3.6 timeline; getting this whole class of upgrade problem out of the next wave's way is the right call.

If the cache delete still doesn't bring it back, paste what's in the e107_value of your SitePrefs row right now and I'll dig further from there.

[BillyBoy0823]

You ARE AWESOME!!!

I do delete cache a lot, on site and I have a lil script I run, but removing THAT FIle did the trick!! Awesome.

Saves me from another install. Thank You SO MUCH!!