Issue: Wiki Active setting is not remembered

Correction: it is remembered. But even when its ticked the wiki is still getting disabled.

The wiki gets disabled if you change any setting that will change page URLs. When the deferred task that rebuilds the URLs is completed, the wiki is automatically re-enabled if it was enabled before.

If you change a setting on the same page while this is happening, and you leave it unticked, then the deferred task will be notified that the new desired state is disabled, and that it should not automatically re-enable.

Please add this information to the page. its extremely confusing when this happens.
Better yet: show a notice when this is triggered.

I dont know but I cant get the wiki activated. Maybe I need to wait longer than an hour. But it does not seem to be working.

Your other issue (https://www.vaultwiki.org/issues/5204/) had caused the deferred task responsible for rebuilding settings to enter a failed state. I reactivated the task manually and it completed.

How did you do that? I ask because I expected this to be the case and tried to set the state by saving the options page again.

Saving the options again will not reset the state; it will only update the list of options that need to be rebuilt by the settings rebuild task.

It can be manually reset with a MySQL query:
We set a failed state on a given task-type (here, "settings") when a rebuild request set a unique lock over 60 seconds ago. If the lock has not been released yet, we assume that either the PHP timeout was reached or an error occurred. We assume that running the same task again will result in the same errors, so it is placed "on hold"; if we did not assume this, a denial of service condition would be started, infinitely retrying deferred.php (see: VWE-2014-0383). Normally, developer attention is required to resolve the underlying issue that triggered the error, so failed states are reset by running the upgrade script (in case the bug fix was part of the upgrade).

When a notice is added to this setting, it would be useful to state whether the rebuild has failed, to provide information about how to look into it, and to provide an easy way to try again.

I'm sorry but I am not following. If I do not change anything on the setting page, but only set the wiki to active, then how long will it approximately take before the wiki is turned on?

As I have just discovered, this setting is broken in Patch Level releases due to a failure to properly calculate whether an upgrade is pending (because of the "Patch Level" version name). I have (in the last 5 minutes) updated the current patches with the hotfix. Once the hotfix is applied, it should be possible to reactivate this setting under patch level releases.

I have applied the patch. It was active after that. After disabling the wiki, it seems I cannot re-enable it again. Does it need an amount of time to go back on?
I did not change any settings.

It looks like your wiki is back on again, so I figure you had another deferred task in the queue that completed after your post.

I have noticed that "Load Font-Awesome Files from Remote Third-Party" always triggers the deferred rebuild even when it was unchecked before and remains unchecked. I have fixed this issue for the next release.

I have also changed it so that any hold placed on the task is automatically removed when saving settings again. If anything this should throw more errors in the log so that the admin will know why the task is failing.

Thanks!