VaultWiki [Paid] 4.1.7 Patch Level 1

[pegasus]

Okay, I've looked into this, and there's not a bug in VaultWiki. The XenForo_Application::loadConfig method uses 'require' instead of 'require_once' to load the config file. The expectation is that 'require_once' is not needed because config.php only sets keys on the $config array. It does not cache the config output in that method. Thus, subsequent calls to XenForo_Application::loadConfig (which VaultWiki makes) will read from the config file each time.

Since XenForo intends to allow reading from the config.php file multiple times if needed (require instead of require_once), your placement of PHP code that cannot run multiple times there is a problem. Ideally, the code that actually registers the stream wrapper would be a code event listener somewhere like init_dependencies, but if you need it to happen during XenForo upgrades, you can just wrap your $s3 lines so they only run once.

I've updated VaultWiki so that it doesn't go through ::loadConfig. I think this is leftover from early RC and nowadays the config is available another way. I consider this change to be a simple micro-optimization, since there is nothing really wrong with the current way. In vault/core/controller/db/xf.php, find:

$config = XenForo_Application::getInstance()->loadConfig();

Replace with:

$config = XenForo_Application::getInstance()->get('config');

 

[Minecraftly]

Okay, I've looked into this, and there's not a bug in VaultWiki. The XenForo_Application::loadConfig method uses 'require' instead of 'require_once' to load the config file. The expectation is that 'require_once' is not needed because config.php only sets keys on the $config array. It does not cache the config output in that method. Thus, subsequent calls to XenForo_Application::loadConfig (which VaultWiki makes) will read from the config file each time.

Since XenForo intends to allow reading from the config.php file multiple times if needed (require instead of require_once), your placement of PHP code that cannot run multiple times there is a problem. Ideally, the code that actually registers the stream wrapper would be a code event listener somewhere like init_dependencies, but if you need it to happen during XenForo upgrades, you can just wrap your $s3 lines so they only run once.

I've updated VaultWiki so that it doesn't go through ::loadConfig. I think this is leftover from early RC and nowadays the config is available another way. I consider this change to be a simple micro-optimization, since there is nothing really wrong with the current way. In vault/core/controller/db/xf.php, find:

$config = XenForo_Application::getInstance()->loadConfig();

Replace with:

$config = XenForo_Application::getInstance()->get('config');

Thanks, I'm able to open the Wiki panel normally now.

 

[Minecraftly]

I'm not sure why but right now Vault Wiki page doesn't display properly, it was fine an hour ago when I installed it:

https://gyazo.com/ba5406e04d9d460811af9a5e1b9eb5d1
https://gyazo.com/46cc97791c813254d62b41ce129a83a9

Note: I haven't made any changes to Vault Wiki, nor created any pages.

 

[pegasus]

The style is not fully cached. Try disabling the addon, then re-enabling it.

 

[Minecraftly]

The style is not fully cached. Try disabling the addon, then re-enabling it.

It's still the same.

It might have to do with memcached I think.

 

[pegasus]

Does it look fine when memcached is disabled?

 

[Minecraftly]

Does it look fine when memcached is disabled?

No, I tried disabling memcached instance and in the config. It was still like that.

EDIT: It's fixed after a few minutes of disabling memcached. Can you please make it work well with Xenforo memcached? Thanks.

 

[Minecraftly]

Can you help me figure a fix for that?

 

[pegasus]

No, I tried disabling memcached instance and in the config. It was still like that.

EDIT: It's fixed after a few minutes of disabling memcached. Can you please make it work well with Xenforo memcached? Thanks.

If it took a few minutes and you didn't make any other changes, it's possible that's how long it took the style cache to rebuild, although it should have been fully rebuilt before the "Installation Complete" message. If it deferred it until after installation, which does happen to some people but it's never happened to me (and that may be due to Memcached which no one has ever mentioned before), then how long it takes depends on how many add-ons and how many styles your site has. Since it should always be fully rebuilt before the installer says it's done, this leads me to suspect that Memcached is not receiving notification that the cache was updated.

On the other hand, regardless of what cache we're talking about, if XenForo is still reading from Memcached even when the instance is disabled, then there is a problem with XenForo's Memcached implementation. VaultWiki does not use special code to rebuild the style cache; it makes a call to XenForo's own code that does this. It's up to XenForo how it does that, and how it does so with relation to Memcached. If XenForo rebuilds an updated the style cache but hasn't told Memcached it was updated, then that's a problem.

Like I said, I've never had a problem with style rebuilds, so if you notice that it hasn't rebuilt again in the future, you will want to request a Ticket Support service before the problem resolves itself again, or a developer might never see what is wrong.

 

[Minecraftly]

If it took a few minutes and you didn't make any other changes, it's possible that's how long it took the style cache to rebuild, although it should have been fully rebuilt before the "Installation Complete" message. If it deferred it until after installation, which does happen to some people but it's never happened to me (and that may be due to Memcached which no one has ever mentioned before), then how long it takes depends on how many add-ons and how many styles your site has. Since it should always be fully rebuilt before the installer says it's done, this leads me to suspect that Memcached is not receiving notification that the cache was updated.

On the other hand, regardless of what cache we're talking about, if XenForo is still reading from Memcached even when the instance is disabled, then there is a problem with XenForo's Memcached implementation. VaultWiki does not use special code to rebuild the style cache; it makes a call to XenForo's own code that does this. It's up to XenForo how it does that, and how it does so with relation to Memcached. If XenForo rebuilds an updated the style cache but hasn't told Memcached it was updated, then that's a problem.

Like I said, I've never had a problem with style rebuilds, so if you notice that it hasn't rebuilt again in the future, you will want to request a Ticket Support service before the problem resolves itself again, or a developer might never see what is wrong.

I tested again with details, multiple times. It's not that complicated.

Here's my current wiki page: https://m.ly/wiki_index/

I just disabled Memcached, and hard refresh the page, it shows normally right after.

I enabled Memcached again, it's back to showing weird stuffs. Even when I flush memcached, it's still showing weirdly.

I believe the installation was successful without issues. I followed the installation steps manually and made sure everything was done properly.

 

[pegasus]

EDIT: Looking at your web site, the problem is that your CSS is being cut off. Please view this: https://m.ly/css.php?css=vw_block,v...p,vw_additional&style=14&dir=ltr&d=1446330975
You can see that it cuts off in the middle.

If I mess with the URL, it looks like it struggles with any template that contains the CSS @supports block. I'm not sure if this is a minify issue or a cloudflare issue, but @supports blocks are completely valid.

 

[pegasus]

pegasus updated VaultWiki with a new update entry:

Changes in 4.0.7

(released October 31, 2015)

• Header integrations for Content Tags
• Expandable Previews of Long Headers
• Permission for Contributions on Profile
• CSS Class Whitelisting for TABLE/DIV/SPAN
• Style Properties for Wiki Icon Colors
• Fixed wiki BB-Codes disappearing after XenForo upgrades
• Fixed out-of-range permission values
• Fixed database error updating existing masks
• Fixed database error with empty database charset
• Fixed template-only BB-Codes working outside...

Read the rest of this update entry...

4.0.7 includes the fix for the Plagiarizer Vulnerability: https://www.vaultwiki.org/pages/Book/Documentation/XSS:Plagiarizer-Vulnerability

 

[Minecraftly]

EDIT: Looking at your web site, the problem is that your CSS is being cut off. Please view this: https://m.ly/css.php?css=vw_block,v...p,vw_additional&style=14&dir=ltr&d=1446330975
You can see that it cuts off in the middle.

If I mess with the URL, it looks like it struggles with any template that contains the CSS @supports block. I'm not sure if this is a minify issue or a cloudflare issue, but @supports blocks are completely valid.

Very interesting indeed. Thanks for mentioning it.

I disabled "Minify CSS" in Xenforo's Performance Options. It seems to fix it: https://gyazo.com/70d78823d9f5dae64866946c00fba0e9

I haven't updated VaultWiki to the latest version yet. Does the new version fix the same problem?

P/S: Completely different question, but how can I change /wiki_index/ to /index/ only? (For the wiki index page)

 

[pegasus]

The CSS problem is not a problem in VaultWiki. Minify CSS is a built-in function of XenForo and it is failing when it tries to minify @supports blocks. The only thing we would be able to do is silently disable Minify CSS every time when the CSS is expected to contain such a block. I think it is better to let the admin leave it on if it's working. I think it is only broken in some versions of XenForo, or perhaps it relies on a PHP function that is broken in some PHP versions. What versions of XenForo and PHP are you using?

You can change the name of the wiki route in Options > VaultWiki: Site Config > Name of the Wiki Route.

 

[Minecraftly]

The CSS problem is not a problem in VaultWiki. Minify CSS is a built-in function of XenForo and it is failing when it tries to minify @supports blocks. The only thing we would be able to do is silently disable Minify CSS every time when the CSS is expected to contain such a block. I think it is better to let the admin leave it on if it's working. I think it is only broken in some versions of XenForo, or perhaps it relies on a PHP function that is broken in some PHP versions. What versions of XenForo and PHP are you using?

You can change the name of the wiki route in Options > VaultWiki: Site Config > Name of the Wiki Route.

Interesting, I'll try the new version out.

I'm using Xenforo 1.5.2 and PHP 5.6.14-0+deb8u1

 

[silence]

For the Table BBCode, I'm getting this error:

An exception occurred: Undefined index: vw_extra in /home/fdsa/public_html/xenforo/library/vw/XenForo/ViewAdmin/BbCode/Edit.php on line 60

    XenForo_Application::handlePhpError() in vw/XenForo/ViewAdmin/BbCode/Edit.php at line 60
    vw_XenForo_ViewAdmin_BbCode_Edit->renderHtml() in XenForo/ViewRenderer/Abstract.php at line 227
    XenForo_ViewRenderer_Abstract->renderViewObject() in XenForo/ViewRenderer/HtmlAdmin.php at line 78
    XenForo_ViewRenderer_HtmlAdmin->renderView() in XenForo/FrontController.php at line 605
    XenForo_FrontController->renderView() in XenForo/FrontController.php at line 158
    XenForo_FrontController->run() in /home/fdsa/public_html/xenforo/admin.php at line 13

EDIT: Span tag and div tag are broken too

 

[pegasus]

This is frustrating: for some reason the fix for this was not included in the ZIP file, even though it was added to the ZIP file 3 days ago. Sometimes caching is terrible. I cleared the cache again after reading your post and it is now including the fix.

If you receive the vw_extra error, then you already received a wonky cached ZIP and you must run the following SQL query manually before you can modify any BB-Codes:

ALTER TABLE xf_bb_code ADD vw_extra TEXT CHARACTER SET utf8 COLLATE utf8_general_ci NULL

The vw_extra column is the only thing that was missing, so you don't have to worry about other things. (In previous versions, our cache had even given users mixed file versions).

 

[silence]

When a discussion is posted and I try to approve it in the moderation queue, it doesn't work. It just stays in the queue.

 

[SurferJon]

Some questions about Vaultwiki...
1. Can you have templates within templates?
2. Can you have defaults for variables that aren't defined? For example, on MW you can do {{{width|100%}}}, which would set the width to 100% if you don't define the width. If you do define the width, say 80%, then it would set it to 80%.
2. Can it do expressions and switches? Like: {{#ifexpr: {{{gendercode|-1}}} = -1 OR {{{gendercode|-1}}} = 8||<span style="color: blue; font-size: 10.5pt">{{#switch: {{{gendercode|-1}}}|0=Male only|1=87.5% ‚|2=75% ‚|3=62.5%‚|4=50% ‚|5=37.5% ‚|6=25% ‚|7=12.5% ‚|Derp}}

 

[pegasus]

When a discussion is posted and I try to approve it in the moderation queue, it doesn't work. It just stays in the queue.

That was supposed to be fixed in 4.0.7. Are you still using 4.0.6 perchance?