PHP 7.3 to 8.3 and e107 v2.1.1 to 2.3.11 #6101
Replies: 12 comments 23 replies
|
Hallo @KuroiPhoenix, and welcome.
The fix: re-upload that file from the To confirm first, put this in your site root and open it: <?php
$f = __DIR__ . '/e107_core/templates/admin_icons_template.php';
var_dump(file_exists($f), is_readable($f), @filesize($f));What you want is I put v2.3.11 on PHP 8.3.33 here, the same build you are on, and took that file away. The front page carried on serving normally, and the admin died with: A zero-byte copy and a About your own test file, by the way: I ran your three checks against my working install and got the same three One thing for afterwards. If that file did not land, others may not have either, so once you are back in the admin go to Tools -> File Inspector. It checks every core file against the checksum image that ships with the release and lists whatever is missing or altered. If it does not go that way, whether the file comes back healthy or the admin stays dead after you have replaced it, post the three values you got and I will have another go with you. |
|
I took the test; here is the result: /edit |
|
That is a perfect file, @KuroiPhoenix, so my call was wrong. Thank you for testing it that precisely. My mistake was one I can avoid repeating: the error I matched came out of your test script, and I still have not seen what your admin area itself says. So that is what I should have asked for first. The admin's own error, with its stack trace, from your host's PHP error log: Those Meanwhile, here is my current best guess, and a way to test it. I went looking for other routes to that same message, and found one that leaves the icons file untouched: an admin folder still holding pre-2.3 files. Pre-2.3 admin code loads the icon set the old way, the v2.3.11 icons file does not answer to it, and every One way a site ends up there: e107 lets the admin folder be renamed from Same routine as last time, in your site root: <?php
require_once(__DIR__ . '/class2.php');
header('Content-Type: text/plain');
echo "admin folder : ", e_ADMIN, "\n";
$boot = e_ADMIN . 'boot.php';
echo "boot.php readable : ", (is_readable($boot) ? 'yes' : 'NO'), "\n";
if (is_readable($boot))
{
$has = strpos(file_get_contents($boot), 'loadAdminIcons') !== false;
echo "calls loadAdminIcons: ", ($has ? 'yes' : 'no'), "\n";
}
$n = e107::loadAdminIcons();
echo "icons loaded : ", (is_array($n) ? count($n) : gettype($n)), "\n";
echo "E_16_ADMIN : "; var_dump(defined('E_16_ADMIN'));On v2.3.11 that If you get If you get anything else, post all five lines. There is at least one further way to produce this that the probe will not name, so "not the stale folder" is a useful result rather than a dead end, and the stack trace is what would pin it. On going back to PHP 7.3: I would rather you didn't. Undefined constants were only warnings before PHP 8, so the admin would probably limp far enough to run File Inspector, but 7.3 has had no security fixes since December 2021 and v2.3.11 is itself a security release. File Inspector is not the step you need yet either. Let us get you back in on 8.3 first, and it will be waiting for you afterwards. |
|
`admin folder : ./e107_admin/ boot.php readable : yes calls loadAdminIcons: yes icons loaded : 138 E_16_ADMIN : bool(true)` That is the script's response. |
|
Well, maybe it is a good idea to update your site with the whole package, first revert to your original backup and try to update, i think that with the whole version you have a better chance that it works, i use the github version and i do not have these problems... |
|
I missed the edit on your earlier comment, @KuroiPhoenix, and it is the most useful thing in this thread. "I tried doing this under PHP 7.3" tells me you can still get into the admin on 7.3. That changes the shape of this. Undefined constants were only warnings before PHP 8 and became fatal errors in 8.0, so an admin that renders on 7.3 and dies on 8.3 says the constants really are missing during the real admin request, even though the script I gave you finds them perfectly well outside it. Something in the admin page's own start-up is stopping them from being defined, which is why none of my tests have caught it. It also means my last answer was wrong. You asked whether it was worth going back to 7.3 to run File Inspector and I said not yet. You had the better instinct. So: on 7.3, open Tools -> File Inspector and run the scan, then tell me what it lists. Just the first screenful if it is long. It compares every core file against checksums that ship with the release, so it answers "which of my files are not the ones v2.3.11 expects", which is the question my last three guesses were all circling at a distance. If it tells you it has no integrity data to compare against, say that instead, because that is a finding too. One warning about @Alex-e107nl's suggestion. Re-copying every file is a sensible move when you suspect the files, and it may well be where this ends up, but there is a trap in it: do not extract the full package over your existing site. I checked inside the v2.3.11 full archive just now, and the And hold on to that database update reporting "Success" while the button stays active. I am not treating it as a second fault yet, but new code running against a database that still thinks it is on the old version is exactly the sort of thing that shows up as two unrelated-looking symptoms. |
|
To Alex-e107nl: |
|
@KuroiPhoenix e107help, the answer is not fully correct (no data is lost if you don't start the install process again), and Alex approach is one way for people who know what they're doing.. Just unpack the full package somewhere else (locally) and compare folders. But I don't think that this is a real problem. Don't you see the admin login form or what? Or do you see a white page after login in? And update directly from 2.2.1 to 2.3.11? I wouldn't do it, but try using the 2.3.9 files at first; the changes related to sitelinks were after it, and I tested that version. (In fact, I would just replace the sitelink_class file from this version, but it is me) |
|
Thank you very much, I'll give it a try. |
|
To e107help(bot): |
|
(I'm the operator of @e107help.) I haven't been able to run the bot in some days now, partly because I've been busy and partly because I'm recalibrating it for greater autonomy. I hope to bring it back soon so that it can continue supporting you. |
|
I’ve been looking for a download for v2.3.9 but can’t find one. |
|
@KuroiPhoenix On front page right side the releases ar mentioned, click on the +28 releases line. |
|
I urgently need a new pair of glasses. Thank you very much. |
|
I ran the following test (suggested by ChatGPT): error_reporting(E_ALL); echo ' ';'; require_once DIR . '/e107_admin/admin.php'; echo ' ENDE';` The response from e107: START Fatal error: Uncaught Error: Undefined constant "LAN_NAVIGATION" in /home/www/e107_handlers/sitelinks_class.php:975 Stack trace: #0 /home/www/e107_admin/boot.php(259): e_navigation->adminLinks('legacy') #1 /home/www/e107_admin/admin.php(78): require_once('/home/www/e107_...') #2 /home/www/e107-debug.php(20): require_once('/home/www/e107_...') #3 {main} thrown in /home/www/e107_handlers/sitelinks_class.php on line 975 |
|
There ist line 582 |
|
Which language file? There should be 'LAN_NAVIGATION' => "Navigation", in a array with the latest e107.... So, maybe try to setup a copy of your website under a demo folder with a extra database (export db and import) edit e107_config.php with the new database credentials and try to update with the full package when you have the demo working (original)... And you will never lose the original because you have made a full backup as stated everywhere before you started updating? You could also use a local webserver setup to test the full package update with your original backup... |
|
...in the English language file. All lines have this format: |
|
So please download the full package and compare with e107 v2.3.11. here it all works as it should with minor errors, but as i stated i used the full package and there are a lot of ways to test it even locally but you have to put in the work yourself. This is now a oneman (Deltik) show with a bot to help and the rest of us are trying to help but is is all voluntarily.... I know that if I don’t run the full version and don’t overwrite the config file, nothing should theoretically happen. But I’m a coward by nature, and if there’s a risk—even if it’s only "theoretical"—I won’t do it. Then you never should use e107, it is not for the faint of heart :-) |
|
I think I've found it—at least partially: all the language files in the upgrade package are incorrect. The same applies to the full installation version. Do I have to download every single file individually, or is there a way to download the entire directory? |
|
Okay, I downloaded the master file as a zip. The backend is running now, but it looks like this: /edit |
|
I’ve just compared a few files from the master branch with those from the upgrade package; nothing matches—everything is different. I mean, there are always bugs—that’s something you can or have to forgive—but I find it really odd when an upgrade package contains almost nothing but incorrect files. Even |
|
As far as I know, the upgrade packages are compiled from changes made to Git since a certain date. It would be nice if someone tested them; let's see what @e107help has to say about it. I'm synchronized with GitHub itself: https://github.com/e107inc/e107/archive/refs/heads/master.zip After updating, always check for updates, update, and clear the cache, but if you have uploaded all the files, you can never lose your English language files! |
|
Just notice... Up to (and incl) 2.3.11 all is still on full define mode. and the code files will differ (reworked/added/deleted etc..)( as mentioned with each upgrade that those upgrades are for use with lower versions, and would/could be a downgrade for git master. Having the language packs (up to date) in define next to English ( in case github master versions) should make no real difference. (by latest knowledge but tested and using Dutch lang.pack, as for other Lang packs ??). First tests on full ARRAY mode (git master versions + language) are equal fine. |
|
I know I’m being a nuisance—sorry about that. I’ve now carefully copied the files from the GitHub master branch to the server. The frontend is still running, apart from one minor error. The backend is running now too, though there is a small issue. |
|
Corporate is a old css of the bootstrap 3 admin theme tgtje... |
|
Good news before anything else, @KuroiPhoenix: nothing is broken on your site, and you do not need to set it up from scratch. The Site URL box is what stops the save, and you can leave it exactly as it is. Make your edits on Site Information, then click across to any other tab and press Save there. The whole Preferences page is one single form, so that one click posts your Site Information changes along with it, and the Why it happens: on the files you have now, that box refuses any value not beginning with You can type your full address in instead, in the shape of The two things that looked odd both follow from the same script:
@tgtje, that answers your worry about local builds as well: keep the On the upgrade archive, @Alex-e107nl, since you asked what I made of it: the numbers come out in the archive's favour. 66,480 bytes is exactly the One thing worth keeping an eye on. Master got your admin back for a reason you should know about. Where v2.3.11 uses those admin constants raw, so one missing constant is a fatal error on PHP 8, master passes each of them through a fallback and degrades to a plain word and a missing icon instead. Your original fault is covered over rather than cured, and it would return on any future v2.3.x build. If an entry in your admin menu reads "Untitled" or has lost its icon, that is it showing through. Say the word and I will give you a short probe that names the plugin or theme responsible, ten seconds of work at your end. And if the database update still reports Success while the button stays active, tell me and we will take that one next. |
|
Okay, that was it. I really need to enter the full URL of my homepage in the "Site URL" field. That makes it work for the entire site. |
|
The icons were never your problem, @KuroiPhoenix. It is a language file, and the stack trace you posted last weekend said so plainly enough; I did not read it properly. Five rounds on the wrong file is on me. Run this from your site root. It names the file, and it can tell me I am wrong again: <?php
require_once(__DIR__ . '/class2.php');
header('Content-Type: text/plain');
$admin = e107::getPref('adminlanguage');
$lang = $admin ? $admin : e_LANGUAGE;
$file = e_LANGUAGEDIR . $lang . '/admin/lan_admin.php';
$src = is_readable($file) ? file_get_contents($file) : '';
echo "admin language : ", $lang, "\n";
echo "admin phrases file : ", $file, "\n";
echo "format : ", (strpos($src, 'define(') !== false ? 'define' : 'array'), "\n";
echo "has LAN_NAVIGATION : ", (strpos($src, 'LAN_NAVIGATION') !== false ? 'yes' : 'no'), "\n";Three readings, and only the first one is my theory:
For the first row the quickest cure is Preferences -> Language, where Admin-Area Interface Language set to English gives the admin a phrase file that matches your core. Your front end keeps the language it has; only the admin turns English. A language pack built for v2.3 does the same job and keeps the admin in German, and if you would like one and cannot find where they live these days, say so and I will go and look. Where your trace points. The admin menu is one array literal. On v2.3.11, line 964 is its first row and reads e107/e107_handlers/sitelinks_class.php Lines 962 to 976 in 120a38c PHP fills an array literal from the top, so stopping at 975 means everything above it was defined already, icons included. Your That also cancels the plugin hunt I offered you. Last time I said one of your own add-ons had probably poisoned the admin icon set, and offered a probe to name it. You do not need it. Had the icon set been poisoned, line 964 would have stopped the page long before line 975. Why English does not step in by itself. e107 substitutes the English file only when the localised one cannot be read at all (includeLan). A file that is present but old is loaded as it stands, so a phrase added to core later is never defined at all. Before PHP 8 that was a warning and the name printed itself, which is what those What it buys you today. The menu entries that lost their labels get them back. The same fix is what a v2.3.x release would need to bring its admin up at all, if you ever want to move off these development files, but that is a job for a calm afternoon rather than today. I have written the gap up as #6223; whether v2.3.x changes is @Deltik's decision. And if the database update still reports Success while the button stays active, say so and we will take that one next. |
|
A correction to something I told you on 31 August, @KuroiPhoenix, and nothing on your site needs touching: with your full address in the Site URL box, Preferences saves cleanly on any version. What I wrote then was that the box's refusal of any value not beginning with Line 426 in 120a38c @tgtje, you had already caught this. On #6117 on 1 September you quoted that paragraph of mine back with a local v2.3.11 doing exactly what is described there, and I left it sitting for two and a half weeks. Keeping How I came to say it: camer0n made the change twice on the same day in 2025, once on master and once as a cherry-pick onto the release line. I tested master's commit for ancestry, found it nowhere near v2.3.11, and stopped there. A cherry-pick carries a commit id of its own, so that test reports whether one particular commit reached a release, never whether the release has the code in it. Reading the field straight out of the tag takes a second and would have told me. What it changes in practice:
The same wrong sentence is in #6117, where I wrote this up at the time, and it is being put right there too. |
Uh oh!
There was an error while loading. Please reload this page.
I had to update to PHP 8.3 with my hosting provider. So, I downloaded the upgrade package to go from v2.2.1 to 2.3.11. The frontend works, but I can no longer access the backend. A small test file gives me the following message:
`PHP: 8.3.33
SAPI: fpm-fcgi
E_16_ADMIN definiert: bool(false)
E_32_ADMIN definiert: bool(false)
E_16_ADPASS definiert: bool(false)
Direkter Zugriff auf E_16_ADMIN:
Error
Undefined constant "E_16_ADMIN"`
What do I need to change, and where, to get it working again? It is also flagging other missing constants—or rather, undefined constants to be precise; basically all of them starting with
E_16_.All reactions