My awful, awful, upgrade process

Clearly Im missing something here.

I uploaded the files, went to the forum, it had an upgrade message, I upgraded.

Nothing awful, seemed nice and easy to me.
 
Paul M said:
Clearly Im missing something here.

I uploaded the files, went to the forum, it had an upgrade message, I upgraded.

Nothing awful, seemed nice and easy to me.
Click to expand...
Please read my complete post then.

I am glad that your upgrade process was easy. Mine wasn't. I got it upgraded and without damage after all, but that doesn't mean that there is no room for improvement.
 
Even reading your post what I don't understand is the following.

Given that you have a good database backup, as well as a backup of the forum files, as every admin should on a regular basis. Why wouldn't you just follow the prescribed upgrade path and you wouldn't have any problems.

I agree a nice lock password of some kind would be nice, but it would just be a bonus.
 
If you would have asked about your method before upgrading here, you would have known that it doesn't work. So you can't blame anyone but yourself here.
 
I have different needs that probably most of the users and I am experienced enough to know what I am doing. When I encounter something that does not work as something natural or can have bad unexpected consequences I decide to give feedback to the developers in the sense that something as simple as this might save from headaches future users. Myself, I have no problem figuring out the workaround.

I am not blaming XenForo for the upgrade not working, because in fact, I made it work. I am pointing really specific deficiencies in the way they do some things that might lead to unintended consequences and that most likely will be encountered by people pushing the software to their limits. If they want to address them, good, if not, they are free to ignore my feedback.

I think the auto-delete of the lock file is a bad thing, and I also think the redirect to install is a security risk. I think that the no-upgrade path once the file is deleted is a bad user experience. The upgrade was the scenario in which I encountered those issues, but I am really trying to make a point of the backend real things and not on the actual upgrade.
 
Rigel Kentaurus said:
If you rename or move the config.php, the forum auto-deletes the lock file.
Click to expand...
It doesn't do this though. If it does, that's most certainly a bug. That file is only removed if you explicitly removed it. As a matter of fact, there are situations where it's silently created (if you hit the ACP for example), but not silently removed.
 
Rigel Kentaurus said:
I have different needs that probably most of the users and I am experienced enough to know what I am doing. When I encounter something that does not work as something natural or can have bad unexpected consequences I decide to give feedback to the developers in the sense that something as simple as this might save from headaches future users. Myself, I have no problem figuring out the workaround.

I am not blaming XenForo for the upgrade not working, because in fact, I made it work. I am pointing really specific deficiencies in the way they do some things that might lead to unintended consequences and that most likely will be encountered by people pushing the software to their limits. If they want to address them, good, if not, they are free to ignore my feedback.

I think the auto-delete of the lock file is a bad thing, and I also think the redirect to install is a security risk. I think that the no-upgrade path once the file is deleted is a bad user experience. The upgrade was the scenario in which I encountered those issues, but I am really trying to make a point of the backend real things and not on the actual upgrade.
Click to expand...

I believe since your experience is totally different from 99+% of users who upgrade, maybe a different title to your post might be helpful. As it stands, it makes it sound like your experience is the norm for an upgrade when in fact it isn't. Yours was a very unusual upgrade. It's very disturbing to new people coming to the board for the first time and run a standard board.
 
Mike said:
It doesn't do this though. If it does, that's most certainly a bug. That file is only removed if you explicitly removed it. As a matter of fact, there are situations where it's silently created (if you hit the ACP for example), but not silently removed.
Click to expand...

Mike,
Apologies in advance If I am too alarming. That is not my intention. My intention was to share my upgrade process which I think it's awesome for advanced users and why it didn't work.

So... I can replicate it like this
1) Step 1, live forum
2) Step 2, remove config.php
3) Step 3, you will get redirected to the install/ folder

There, it hits this code
XenForo_Install_Controller_Install
Code: 
    public function actionIndex()
    {
        // To get to this, have to get through preDispatch. This covers the situation
        // where config.php has been removed, but not the lock.
        $this->_getInstallModel()->removeInstallLock();

4) Step 4, return the config.php in place
5) Ready, you can wipe the forum

That was what happened to me. I removed the config.php file for a while, and suddenly I had regular users trying to wipe the forum database out of existence.
 
Rigel Kentaurus said:
Thank you very much Peggy. Actually I tried editing a while ago when I realized that the thread was not going the way it was intended... only to remember that I can't edit the title myself :)
Click to expand...
No problem. Just pc me if you need a title changed again in the future. :)
 
Rigel Kentaurus said:
Mike,
Apologies in advance If I am too alarming. That is not my intention. My intention was to share my upgrade process which I think it's awesome for advanced users and why it didn't work.

So... I can replicate it like this
1) Step 1, live forum
2) Step 2, remove config.php
3) Step 3, you will get redirected to the install/ folder

There, it hits this code
XenForo_Install_Controller_Install
Code: 
    public function actionIndex()
    {
        // To get to this, have to get through preDispatch. This covers the situation
        // where config.php has been removed, but not the lock.
        $this->_getInstallModel()->removeInstallLock();

4) Step 4, return the config.php in place
5) Ready, you can wipe the forum

That was what happened to me. I removed the config.php file for a while, and suddenly I had regular users trying to wipe the forum database out of existence.
Click to expand...
Ok fair point, I had totally forgotten about that code (it wasn't in the early revisions). Though if the config.php disappears, then they couldn't do anything to the DB. The problem was that the lock file was removed and then the config.php was restored. I'll think about alternatives.

Generally speaking though, keep in mind that the goals here have been to make it easier for the average person. The redirect to the install if the config.php file isn't there makes total sense from a newbie perspective and it will save various support headaches/questions. This whole thing appeared not only because of the process, but the specific order that all ended up happening.

As an advanced user, I still tend to do in-place upgrades. I tend to just do it via the command line (upload a zip, unzip on the server, cp over top of the existing system). In theory, it can leave some stray files, but generally speaking these won't interfere. Trying to move everything to another directory seems really problematic to me.
 
Mike said:
Ok fair point, I had totally forgotten about that code (it wasn't in the early revisions). Though if the config.php disappears, then they couldn't do anything to the DB. The problem was that the lock file was removed and then the config.php was restored. I'll think about alternatives.

Generally speaking though, keep in mind that the goals here have been to make it easier for the average person. The redirect to the install if the config.php file isn't there makes total sense from a newbie perspective and it will save various support headaches/questions. This whole thing appeared not only because of the process, but the specific order that all ended up happening.

As an advanced user, I still tend to do in-place upgrades. I tend to just do it via the command line (upload a zip, unzip on the server, cp over top of the existing system). In theory, it can leave some stray files, but generally speaking these won't interfere. Trying to move everything to another directory seems really problematic to me.
Click to expand...

I completely agree on the ease of installation.
However, maybe there could be a password on the install page that stops the random users that stumble upon the page? That should be probably be more than enough. Unless you think most users won't know what to type there and choose not to install XF instead :).

I added now a .htaccess rule for the /install folder so I am pretty much covered, but it sounds like something that could exist by default.

Renaming the config.php is not too weird of a scenario. It have even been suggested in vb.org as a quick way to "disable" the forum, especially if for some reason you lost access to admincp, keep access to the filesystem, but don't own the server or can't turn off apache. The answer used to be "remove config.php, people won't be able to use the site anymore".
 
Digital Doctor said:
Should this thread be renamed to:
My awful, awful, upgrade process ----> My awful, awful, upgrade process mistake ?
Click to expand...

Sorry, but no.

Because it is not a mistake at all. My process is a little more advanced than the one the average user would use mostly because they do not have a site with the size my own, have to manage multiple versions, do regression of 100+ hacks and mods and make sure that the upgrade is not a hell in earth.

And all I am asking is that the software do not introduces secondary effects like say, removing lock files if you rename another, or at least document that somewhere. And people can actually run into my scenario eventually, so it might make sense to prevent the pitfalls I am describing.

XenForo is far from shrinkwrap software, one of the main strategic advantages is the fact that it can be customized. The more upgrade paths that we can't prevent from ending into wiping the whole forum the better. If a user cannot upgrade the result should be "cannot upgrade", the result can never be "your whole forum is lost, and we gave normal users access to the admincp".
 
You must log in or register to reply here.

Similar threads

GrumbleShark
  • Question Question
XF 2.2 "No Upgrade available" message when visiting forum home
Replies
6
Views
478
GrumbleShark
GrumbleShark
Chromaniac
  • Question Question
XF 2.3 Question about testing upgrade to 2.3
Replies
8
Views
589
AndrewSimm
AndrewSimm
Doug0928
  • Question Question
XF 2.2 Trying to upgrade from 2.1.1 to 2.2.13
Replies
2
Views
341
Doug0928
Doug0928
X
Installing multiple addons at once ignores addon requirements, leading to unexpected install/upgrade failures
Replies
4
Views
309
Xon
X
Joao Prates
  • Question Question
XF 2.2 2.2.15 - An upgrade was found for a version of XenForo that is newer than the uploaded files
Replies
11
Views
820
Joao Prates
Joao Prates
Top Bottom