Issue: My wiki is disabled and I cant turn it on.

I cannot turn it on. It doesn't turn on after some time either.

I had no trouble turning it on. Checked the box, clicked Save, and it was on. Not sure what the problem was; I only see your Redis errors in your log. I should reiterate though that if the Redis error occurs during a wiki deferred task it is probable that the wiki will get locked like this, so you really need to investigate why your Redis instance isn't working properly.

I don't think it was disabled for too long before you noticed, because there was wiki-related activity by non-admins within the past 3 days.

The only problem I noticed was that guest users were not seeing the "Wiki" navigation item immediately after it was turned on; however, they could visit the wiki directly via other links. This might be a problem with the way the navbar cache is cleared after changing only the active state, or it might just have been a stale cache in Redis (I presume you use it to cache HTML content for guest users).

It has happened many times before that I was not able to turn on Vaultwiki. Something is wrong there. Maybe it only occurs in Firefox.

In regards to fixing the redis errors: the fix is to find a new host.

I know it has happened to you in the past; however, in the latest version, you are now able to "retry". By saving settings again, it re-queues the hung rebuild task. If the task still does not complete, it is important to check your logs for associated errors.

While investigating this report, I found a bug in vBulletin where retrying actually saved the wiki into a disabled state, rather than the desired state. This could be corrected by re-enabling after the task succeeded. However, this bug did not affect XenForo at all. This is fixed in the next release.

While investigating this report, I found a race condition, where the temporary-disable during the retry is not re-enabled, if the retried task ends up completing after the retry is submitted but before the retry is committed to the database. The timing for this is very unlikely, would require a PHP execution timeout of more than 60 seconds, and would require a MySQL connection timeout of at least the same. This is fixed in the next release.

While investigating this report, I found a different bug: a retry is not even attempted if the only setting you change is the Wiki Active state. In this case, a failed deferred task is ignored and the wiki is re-enabled anyway. This could lead to data sync issues, but it means that it was possible to re-enable your wiki at any time (as I was able to), provided you only changed that one setting, and provided that a deferred task did not later complete for which you had specified a wiki-disabled state upon completion (that is, left the Wiki Active state unchecked while changing a different setting). This is fixed in the next release.

While investigating this report, I found a bug which might be what you are experiencing. When changing a setting that requires a rebuild, the wiki active state is changed, as normal. While this is still occurring, you might alter setting on a page that does not contain the Wiki Active box. The new rebuild is queued after the previous rebuild, but now thinks that the current active-state is disabled (it is, because of the existing rebuild) and to preserve that (which is wrong). When all rebuilds complete, the active-state is therefore set to disabled. In order to correct this issue, a separate setting must be used for rebuilds that affects the active-state without actually altering the Wiki Active setting. This is preferable to having a deferred task pass the active state to the next task, because a hung task with the desired state would not pass the state to the new task. By always preserving the original state in the setting value, we can show the correct state on the settings page, include an appropriate notice, and provide a status checker for tasks that affect whether the state is actually being applied to visitors.

While developing the above fix, I found a different bug which only has a negative effect in vBulletin. When changing a setting that requires a rebuild while the active state is disabled, the rebuild is never marked as completed. Thereafter, when trying to save the Wiki Active state as enabled, the state change will never succeed (in 4.0.20 it will succeed after 60 seconds have passed), because an open task is detected.

Marked as Fixed in the next release. The aforementioned bugs are fixed. In addition, the vw_enabled setting (Wiki Active) is no longer modified directly by deferred tasks. Instead, they set a vw_maintenance flag.

When vw_enabled is not set (previous behavior):
- Only admins can access the wiki.

When vw_enabled is set and vw_maintenance is not:
- All users can access the wiki.

When vw_enabled is set and vw_maintenance is set:
- Only admins can access the wiki.
- When viewing the vw_enabled setting in the AdminCP, the setting is greyed out and a notice is displayed:
We also check for the health of the deferred task here. If the task failed, a different notice is displayed:
These changes should eliminate accidental changes to vw_enabled. They should also reduce confusion about why the "wiki is disabled and I cant turn it on".