Issue: No images showing after update

Actually all VW-supplied BB-Codes were not rendering. I have logged into your wiki and triggered a cache rebuild, and they are rendering now.

From what it looks like, the act of disabling VaultWiki before upgrading (as is recommended for the XF 2.3 update) sometimes results in the BB-Codes getting stuck in the disabled state even after the upgrade has completed.

The upgrade is supposed to automatically re-enable BB-Codes disabled prior to the upgrade, if they were disabled by disabling the add-on. However, for some reason, on some installations, those BB-Codes are not being re-enabled.

By the only bug I found, this could happen if the first time you disabled VaultWiki, after upgrading to 4.1.5 or higher, if you already had all VW-supplied BB-Codes disabled, then it remembered that state and kept using it. The bug I found is that the first BB-Code state ever found when disabling the add-on is never replaced by newer BB-Code states at the next time you disable the add-on, causing BB-Codes to always revert back to the state from the first ever disabling after upgrading to 4.1.5.

However, since it was simple enough to trigger the active states to rebuild on your site, then your site was not affected by that bug, and something else is going on.

That bug may also occur, and be possible for your site, if there is no MySQL UNIQUE index on table vw_log for logtype, dateline, loghash. In that case, we would still log new BB-Code states but a random state would be returned each time we try to re-enable them.

thanks a lot!

This happened to me again on another site I upgraded today, so something strange is definitely going on here. I will have to do a few more test upgrades from XF 2.2 to 2.3 to see what causes the BB-Codes to get stuck as disabled.

This is fixed for upgrades starting with the next release. The problem was as follows:

The recommended procedure for upgrading to XenForo 2.3 is to disable VaultWiki first, then upgrade XenForo and upgrade VaultWiki while it is still disabled.

1. When VaultWiki is disabled, it manually disables custom BB-Codes that are installed or managed by the add-on, but which are not associated with the add-on's data XML. Normally these will be automatically re-enabled the next time VaultWiki is re-enabled.
2. *When clicking to upgrade VaultWiki, XenForo's upgrade system re-enables VaultWiki and sets the processing flag, but it specifically prevents jobs that should be triggered by the active-state change from being triggered.
3. When VaultWiki's upgrade begins processing, it detects that the processing flag is on. Since this would prevent some needed class extensions from working during upgrade steps, VaultWiki turns the processing flag off and re-enables VaultWiki. It was expected that this change would trigger the active-state change jobs. However, VaultWiki was unexpectedly already re-enabled by the previous step, so the active-state is not actually changed, and no jobs are triggered.
4. Any BB-Codes that were disabled during step 1 remain disabled throughout the upgrade process and even afterwards, until the admin manually re-enables them.

This is resolved in the next release by adjusting step 3 so that active-state change jobs are always triggered. Since we don't know the original active-state thanks to step 2, we just have to assume that the add-on was in a disabled state at the time the "Upgrade" button was clicked.