Please read my complete post then.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.
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.If you rename or move the config.php, the forum auto-deletes the lock file.
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.
Same here.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.
Please note I am not saying that the upgrade process is awful. I said that MY experience with the upgrade process was awful.Same here.
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.
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();
There ya go!Feel free to edit the thread title as you are a mod.
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 myselfThere ya go!
No problem. Just pc me if you need a title changed again in the future.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
That's better...cause it is your experience, which is true.Please note I am not saying that the upgrade process is awful. I said that MY experience with the upgrade process was awful.
Feel free to edit the thread title as you are a mod.
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.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.
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.
Should this thread be renamed to:
My awful, awful, upgrade process ----> My awful, awful, upgrade process mistake ?
Sorry, but no.
We use essential cookies to make this site work, and optional cookies to enhance your experience.