Issue: 950% upgrade, crashing whole site, yade yade yada. Posted about this on XenForo

It is possible the patch you downloaded was not the correct one for your original version. Please download the full package and see if the upgrade will complete.

It would be great if you can remember the correct version you had before, so that we can repair your vw_upgradelog table. Can you post the current contents of the vw_upgradelog table?

Will the full download delete all of the wiki posts? We have over 600 wiki posts, so we cannot do anything to have them removed...


Also, where can I find the vw_upgradelog table at in the ftp?

The full download only uses more of our bandwidth and takes longer to upload to your site.
The only thing that would delete your wiki posts is if you uninstall the add-on from XenForo's AdminCP.

The vw_upgradelog table exists in MySQL. It depends on your server how you would read it. Many servers use phpMyAdmin.

http://i.imgur.com/oaQJm2Z.png

that is a picture of the table.

As for upgrading it once again, when I enable the wiki it now crashes my site, and that is devastating for us. With around 1k views an hour, it puts a lot of hurting on our views, traffic, and money when the site isn't up...

Did you used to use the Lite version?

I don't see a reason in the vw_upgradelog table that would lead to an infinite loop.

In XenForo AdminCP > Home > Options > Debug Options (you might need to turn on XenForo debug mode first to see this option), set VaultWiki Version = 4.0.6
Setting the version to the incorrect number here will cause VaultWiki to skip all of its code because it will expect to crash when the version number is wrong.

So, after that change you should be able to re-enable VaultWiki without crashing your site.

In the vw_upgradelog table, edit the 'version' for upgradetype = C so that the version is 4.0.6.

Then please try the upgrade again.

If the upgrade fails/goes into a loop again, please copy and paste the entire contents of the progress window. There might be a clue just before it starts looping.

If this becomes too much for you or it doesn't work, you are welcome to open a ticket here: https://www.vaultwiki.org/members/?do=tickets
And we will figure out what's going on with your installation.

uhh... could you talk me through everything step by step, as I have no idea what you're talking about with changing the version and everything. I never had to trouble shoot a plugin I purchased before, especially one I have to re-purchase everymonth just to get it to work, and to find out it doesn't work. Every purchase I've had to make in the past with plugins (all being single, one time purchases) instantly worked. I guess it's the payment plan plugins or something, so seeing as I'm new to this, I'm not really tracking how to do any of this.

1. In library/config.php, add the following line:
2. In the XenForo AdminCP, go to Home > Options > Debug Options, and change VaultWiki Version so it says 4.0.6

3. In phpMyAdmin, edit the vw_upgradelog row where upgradetype = C. Change the version field so it says 4.0.6

4. In XenForo's AdminCP, re-enable the VaultWiki add-on.

5. In the XenForo AdminCP, go to Wiki > Maintenance > Run Upgrade Script.

6. If it fails again, copy the entire contents of the progress window. We will need it to see what happened. If your site crashes again, re-disable the VaultWiki add-on like you did before. If this happens, you should submit a ticket so a developer can look at your site more closely: https://www.vaultwiki.org/members/?do=tickets

It's unfortunate that you have re-purchased every month just to see if it will work. When you encounter a problem like this, it is better to file a ticket and get it resolved right away. This is better for everybody, and it will save you money in the long run. Support is included in the price you paid, so there is no reason not to use it. If you just assume a later version might work, you risk complicating the issue when you upgrade on top of something that's already broken.

Please let me know how far you get with the upgrade this time, or if you open a private ticket.

Since I have not heard back and you have not opened a ticket, I'm assuming the steps above fixed the problem.

From the original description it sounds like this was related to a bug in the upgrade system since 4.0.0 Alpha 1 that was resolved in 4.0.9. However, some databases that were already affected by the bug needed to be rolled back using the steps above in order to repair the damage. Still, I am surprised that the bug affected post-4.0.9 upgrade steps.

I am leaving this report open as a reminder to our developers that logging of the upgrade process should be improved so that a record of all steps that were completed is maintained, rather than just the last completed step, should that record be needed later to diagnose an issue. The vw_log table has existed since 4.0.0 Alpha 1, and should be usable for these purposes. For steps prior to 4.0.0 Beta 7, a special condition should be used, since vw_log.loghash was not available until that version.

Starting with the 4.0.11, more granular logging of the upgrade process will take place. While this will not directly resolve any upgrade problems, it will maintain more information for support to know whether any crucial steps may have been skipped in the past that may lead to an issue or itself be a warning of one.

This report is now closed.