Issue: So many problems!

Please upgrade to the latest version. The issues you are facing may already be resolved in a newer release. Beta 4 was 12 versions ago.

Once your version is updated, please modify your original post regarding the issues you've noticed, and leave a reply that your post was updated.

I followed your instructions with some trepidation. It [the upgrade process] appears to have frozen at 1%, and the entire website is down with the error:

This includes the adminCP, so I can't access that now, either.

And now I can't even get to the install page. In Firefox is gives the above error, in IE it gives a different one:

Not that I understand it, but that error appears to be looking for a directory called packages/vaultwiki/

There's no such directory in the product ZIP. There's one called packages/vw instead.

OK, you're not around right now. I'm going to try manually removing all the VW files and hope that helps. I can't afford downtime at the moment.

Well, removing all files improved it from an error message to just a blank white page.

Any help here? I paid you more money and did what you told me to do when you told me to do it. Now you've vanished, and a business which lots of people rely on has also vanished. You told me to do it.

Anything? At this point, after years of expense and time, I'd simply appreciate advice on how to safely remove this software. The install/remove page was inaccessible after the file upload you told me to do. I just want to remove it and walk away; please help me do that. Downtime is expensive.

Telling me to pay you more money and do something, then walking away for 9 hours is not an environment I can afford.

Oh, FFS. So I figured the way to fix this was to re-upload the files from the version I was using before, which didn't work correctly but at least allowed the rest of the site to operate. Maybe I could uninstall from there.

But that version (4.0.0 Beta 4) is no longer available.

What should I do? How do I get this thing off my server and go back to running my business?

OK, it's nearly 3am here and I've spent nearly 13 hours straight on this with no success. I'm going to head to bed now, as it's been a long, long day of trying to fix this mess and I'm utterly exhausted. I really hope there will be some advice tomorrow. My last attempt has been to re-upload the 400g7b3 package.

Sorry for not being around today, but Sunday is not typically office hours. Support can generally only be expected Mon-Fri 9-5 ET.

"In-Place Upgrades," (1. upload files, 2. run upgrade script; nothing else) which is what it sounds like you had attempted, were not possible until Beta 6 (and you had Beta 4). Even if you only needed to upgrade 1 or 2 versions, you still needed to disable the product before upgrading, per the instructions you were used to in Beta days. This was a serious design flaw in early versions (as you noticed), and that's why we fixed it almost a year ago in Beta 6.

To upgrade from versions before Beta 6, you MUST disable the product before uploading new product files, and you MUST NOT re-enable the product until the upgrade process has completed fully and successfully. You can only disable the product in the AdminCP, from Plugins & Products > Manage Products. Since you have run into errors, you probably need to set DISABLE_HOOKS in includes/config.php in order to even get back there.

Once the product is disabled, the errors will stop, and you should be able to run the upgrade script.

* You noted that Beta 4 is no longer available. As per our security and EOL policy, we remove versions that had security vulnerabilities (the most recent known vulnerability affected < 4.0.0 Gamma 3). We always email members whenever vulnerabilities are discovered, encouraging them to patch their installations at the time, since the exploit then becomes public knowledge.

I have made a change for RC 3 that will attempt to allow In-Place Upgrades to work against pre-Beta 6 versions, but that does not help you now, and it would only work under specific circumstances anyway.

I was following the instructions in the package you told me to download. There's a README which says "Follow the instructions at:
https://www.vaultwiki.org/manual/vaultwiki-4-manual". I went to that URL, saw an icon wjhch says "Install/Upgrade" and clicked on it, and found a page which said "In VaultWiki 4, it is no longer necessary to disable VaultWiki completely before starting the upgrade. In fact, VaultWiki must be enabled in order to access the upgrade script in some forum environments." If there were additional instructions telling me to disreagrd that, I did not see them. You might want to add them to that page or make them clearer if they're there and I managed not to see them.

Anyway, that's by-the-by. So this morning we managed to get the site up again, although I haven't opened it. I had to enlist extra help to resurrect things, and have this report on the current status:

So it looks like I screwed up with the config file in some way? I'm a bit more nervous about that copying and renaming of the vw to vaultwiki directories.

I already know the install stopped at 1%, so it hasn't installed correctly (plus certain areas, like profiles, simply give database errors). However, I don't dare touch anything right now for fear of breaking it all again (plus we don't know the effects of what was done to bring it back up).

So I don't really know how to proceed, and am largely afraid to do so.

One thing I did just do was disable VaultWiki from the adminCP, which seems to have worked (though user profile pages are now blank).

If you can, please fill this out and I will do my best to get you back up and running in full swing ASAP: https://www.vaultwiki.org/members/?d...e&productid=20

Sure thing - done. Thanks!

Took a long time, but your wiki is upgraded to the latest release.

Once VaultWiki was disabled as discussed above, the upgrader seemed to go smoothly for a while. However, it did hang for a while and some functions needed tuning, as I believe I found why your installer was frozen at 1%.

You have a lot of wiki pages with over 100,000 characters. Some have over 300,000, which is the theoretical limit according to VaultWiki stress tests, before stock PHP configurations tend to time out. It takes a long time to parse text that long, and the upgrader was trying to batch several thousand pages at once. Although some tuning has been done to reduce latency when dealing with long pages, please be advised that your server is still not happy about them.

If you can, I would advise restructuring those pages and splitting them into a number of shorter pages below 100,000 characters. You can see a list of slow pages like this on Special:LongPages.

Anyway, now that you are upgraded to a more stable release than you had before, you can revisit the issues from your first post to see if they still persist.