Sanity check for one-click updater when admin/system have been renamed

Our site’s /system folder is renamed and I had the same issue when I tried using the one-click updater to go from 4.3.6 to 4.3.8. I agree, it would be nice if the updater could handle this scenario, or at least check for it and notify the user before attempting the upgrade.

The updater can handle renamed admin.php and renamed system folder above-web-root, i.e. All The Scenarios. That error message indicates that you did not update your admin.php and index.php files when you upgraded from v3 to v4/5, and is the sanity check in pre-flight to make sure the updater can run. 😊

Thanks, Derek. Can I break that down a bit?

The updater can handle renamed admin.php and renamed system folder above-web-root, i.e. All The Scenarios.

Are you saying here that it should/shouldn’t also be able to handle renamed admin.php and /system in the conventional location?

That error message indicates that you did not update your admin.php and index.php files when you upgraded from v3 to v4/5, and is the sanity check in pre-flight to make sure the updater can run.

99.9% sure that I updated both of those (it’s possible I glossed the error message wrong here; meant to save it to quote directly, forgot). I try to follow the manual upgrade directions pretty closely. Also, given that the updater worked fine after just renaming admin.php and /system back, wouldn’t that suggest that the files themselves were fine?

Are you saying here that it should/shouldn’t also be able to handle renamed admin.php and /system in the conventional location?

No, sorry, just saying that it handles everything that works to run ExpressionEngine, including our best-practices recommendations. Indeed our updater hopes you’ve done that.

Also, given that the updater worked fine after just renaming admin.php and /system back, wouldn’t that suggest that the files themselves were fine?

If you indeed updated those files and renaming was all it took to fix it, then it was likely an opcache, where PHP was reading your admin.php from memory instead of on disk, so it was still compiling with the v3 admin.php. You can always double check by comparing your admin.php file’s contents to a fresh download, or on GitHub.

If you indeed updated those files and renaming was all it took to fix it, then it was likely an opcache, where PHP was reading your admin.php from memory instead of on disk, so it was still compiling with the v3 admin.php.

Aha, sounds plausible. (It might be a while before I’ll be in a position to test.) Maybe the updater could opcache_reset (or something similar)? Anyway, thanks for clarifying.

Maybe the updater could opcache_reset (or something similar)?

It does, however there are some environments that don’t allow an individual client to reset it, as the opcache is shared with other users on the server. We don’t even try if that’s the case, as it will create PHP errors. You can check your PHP Info page for opcache.restrict_api to see if that’s the case. If that’s not it, then, um… Gremlins? Either way, you should be safe to rename it back to your obfuscated file name. If you run into trouble again, please cut and paste the error verbatim or submit a GitHub issue if you’ve found a reproducible problem that isn’t accounted for. Thanks Paul!

Okay, some closure on this. I hit the same error attempting the one-click update from 5.1.1 to 5.1.2, and caught the full error message:

It looks like your ExpressionEngine installation is using an out-of-date /admin.php or /system/index.php file.
Please make sure you have the latest version of each file in place and then try upgrading again.

I was looking in the wrong place. The issue was an old version of /system/index.php, not an old version of /admin.php. Once I uploaded the EE5 version of /system/index.php, the 5.1.1 to 5.1.2 update ran smoothly. The version of /system/index.php I was using had been left over from the manual EE3 to EE4 update.

But, I’ve looked through the EE3 to EE4 manual update instructions, and I really don’t see a step that would have updated /system/index.php:

https://docs.expressionengine.com/v4/installation/upgrade_from_3.x.html

Am I being an idiot and missing it, or is it really not there?

No, you’re not, looks like it’s not explicitly mentioned. Is your system/index.php file publicly accessible though, and is it also the URL you access your control panel with? The system folder should be placed above web root in a location that’s not accessible by a web browser.

Derek:

No, you’re not, looks like it’s not explicitly mentioned. Is your system/index.php file publicly accessible though, and is it also the URL you access your control panel with? The system folder should be placed above web root in a location that’s not accessible by a web browser.

/system is renamed, but, yes, it’s publicly accessible and is the URL I use for the CP. I’ve considered moving it above web-root but haven’t got around to that yet.

I sort of like being able to use mysite/system (where ‘system’ is super-secret rename) as the CP login, though. It can be especially useful for the less-techies that use the back-end, for whom /mysite/super-secret-rename (which defaults to /mysite/super-secret-rename/index.php) is simpler and more memorable than /mysite/super-secret-name.php. They don’t know what PHP is, and shouldn’t have to.

To go back to the start of this, I was stupidly imagining the updater was checking that admin.php was up-to-date, even if that hadn’t been used to run the updater. (If I was running /system/index.php, how could it know what admin.php had been renamed to?) Hadn’t occurred to me that it was just checking the file it was actually running. Doh.

Anyway, I honestly don’t think the sort of set-up I have is too crazy (https://example.com/system/ is explicitly given as a canonical URL for the CP in the update instructions, for example), so it would make sense to explicitly list the updating of /system/index.php in the EE3 to EE4/5 process.

I agree that the instructions should list that explicitly, but that’s a separate issue of a) whether you should run a production site that way (you shouldn’t) and b) solving the issue of a friendly control panel URL for your content authors.

For (a), see moving the system directory above webroot. The docs describe why the application can’t ship that way in the download even though it is the way we strongly recommend that everyone install it. Having your system and user files available via a web request is a security and information disclosure risk, and changing the folder name doesn’t cut it.

For (b), I contend that you’re making a problem where there is none. Folks don’t type URLs, they click on them. They may see .php once, but they don’t even have to do that if your instructions are given to them in HTML format. Then they can bookmark it. Either way, they’d only ever encounter it once, and even my mother isn’t likely to bat an eye; it’s not exactly uncommon. But even if it is aesthetically offensive, violating the best practice (a) is not the only way to solve it and certainly not the best. You can simply create a .htaccess rule to rewrite any simple URL pattern you like to route those requests to the back end script, e.g.

RewriteRule ^you-have-the-power/?(.*)$ /obfuscated-admin.php/$1 [L]

Derek:

I agree that the instructions should list that explicitly, but that’s a separate issue of a) whether you should run a production site that way (you shouldn’t) and b) solving the issue of a friendly control panel URL for your content authors.

I think I’m coming across as argumentative here, and I really don’t mean to be. You’re totally right to push for moving above webroot, and my not doing that is 99% that I just haven’t got around to it yet. And I totally could/should provide my own redirect to the CP login. Just, you know, lazy, pragmatic, real-world cases.

A thought about security, though. Not sure I completely agree about typing vs. clicking on links. There’s a security that comes from not actually needing to write stuff down, and something being memorable is part of that. I literally do not have the super-secret CP rename written anywhere, and I pass it to users in person. They might well bookmark, use a post-it, whatever, obv., but having something (physical or web) that formally documents a super-secret login seems to be counter-productive.

Anyway, please go do something way more useful. (And thank you.)

I don’t think you’re being argumentative, and I’m trying to advocate for pragmatic, real-world cases. These are not things that provide theoretical benefit, nor are they difficult or time consuming. Think of it as whether or not you should ever change your oil after buying a new car. You can probably go a loooong time without ever doing it if you never think about it or stop to do it. 😛

FWIW, I was thinking of emailing instructions, where nearly every app automatically converts URLs to links. If you’re telling it to them in person, you’re probably saying it to them out loud over their shoulder, and can say “dot P H P” at the end. But again, the more aesthetic and memorable is easy to achieve. Either way, they don’t have to actively bookmark it. Every modern web browser is automatically doing that by default, in the form of Favorites / Frequently Visited / Autocomplete / Quicklinks / etc. and is probably even visiting that URL in the background to update a screencap without the user requesting it. I doubt they have to remember anything but the first few letters of their domain name at most, even if they are habitual typists. 😉

Have a great rest of your week Paul!