VaultWiki [Paid] 4.1.7 Patch Level 1
- Thread starter pegasus
- Start date
Ezenity
Active member
Is vautwiki compatible with "BbCodes & Buttons Manager" ?
pegasus
Well-known member
There are no known conflicts between the latest version of BbCodes & Buttons Manager and the latest version of VaultWiki.
BB-Codes are added to XenForo 1.3+'s built-in "Custom BB-Codes" manager. VaultWiki does not add any additional records unique to BbCodes & Buttons Manager.
Ezenity
Active member
Okay, so then do I report this here to you or to "BbCodes & Buttons Manager?
Vault Wiki BbCodes show in reply box (Note this reply box is in a thread not associated with vault wiki)
However, in the Buttons Manager it is not activated. I tried going through all options in acp and other areas to try and fix this but can't seem to figure it out.
pegasus
Well-known member
It looks like a bug in VaultWiki. Custom BB-Codes, including VaultWiki BB-Codes, will appear in the Quick Reply box in default XenForo, from what I understand (another test BB-Code I made appears). In any case, the Wiki-Related "Show in editor" option will take precedence over whether it is activated or not in the buttons manager, and buttons flagged as wiki-related will use the VaultWiki grouping instead of the buttons manager grouping. This is expected. However, it seems like unchecking the "Show in non-wiki editor" option in the BB-Code manager has no effect. I can duplicate this behavior on my test board so I don't think it's related to the other add-on.
For now, a temporary solution would be to blank the editor icon fields for the BB-Codes that are showing, but this will make them disappear from the toolbar in the wiki too, and you would have to remember to set the fields back after a fix is posted.
pegasus
Well-known member
To fix "Show in wiki/non-wiki editor" not having any effect, edit library/vw/XenForo/ViewPublic/Helper/Editor.php. Find:
Replace with:
Then, to remove the unwanted buttons, edit the BB-Code in question via XenForo's BB-Code manager, switch to the "Wiki-Related Options" tab, and uncheck the settings that add the buttons to the editor.
Code:
if (
!vw_Hard_Core::model('Tag')->parse_for($tag, $for) OR
!vw_Hard_Core::model('Tag')->check_field($tag, $prefix . '_editor')
)
{
continue;
}
Code:
if (
!vw_Hard_Core::model('Tag')->parse_for($tag, $for) OR
!vw_Hard_Core::model('Tag')->check_field($tag, $prefix . '_editor')
)
{
unset($options['json']['bbCodes']["$tag"]);
continue;
}Ezenity
Active member
Worked like a charm, thank you!
pegasus
Well-known member
This weekend, our developers discovered a "Cross-Template Vulnerability" in paid versions of VaultWiki: https://www.vaultwiki.org/articles/177/
It affects XenForo installations, and the attack involves patience and multiple templates.
There are patches for versions released within the past year.
It affects XenForo installations, and the attack involves patience and multiple templates.
There are patches for versions released within the past year.
Alpha1
Well-known member
How is vaultwiki 4.1 coming along?
Would you be so kind to write a blog post about it? This is the release that we have been waiting on for so many years that will finally implement features that have been scheduled for implementation as early as 2010. It seems to have many functions that give much tighter integration with xenforo.
For us this is the release that will show us what direction we need to head for wiki. Either vaultwiki is the right way to go or we need a xenforo native solution that is close to AMS.
Would you be so kind to write a blog post about it? This is the release that we have been waiting on for so many years that will finally implement features that have been scheduled for implementation as early as 2010. It seems to have many functions that give much tighter integration with xenforo.
For us this is the release that will show us what direction we need to head for wiki. Either vaultwiki is the right way to go or we need a xenforo native solution that is close to AMS.
pegasus
Well-known member
I cannot reproduce the problem with the arrows. What browser are you using?
For the parsing, have you tried clearing the cache: Wiki CP > Maintenance > Rebuild Counters / Caches > Cache Parsed Content? I cannot reproduce this problem either on the newest version (it was a bug in a really old version; maybe it was saved in cache that way).
For the parsing, have you tried clearing the cache: Wiki CP > Maintenance > Rebuild Counters / Caches > Cache Parsed Content? I cannot reproduce this problem either on the newest version (it was a bug in a really old version; maybe it was saved in cache that way).
Infopro
Active member
I can, using FireFox. Safari and Chrome seems fine.
Attachments
silence
Well-known member
It fixes it for the first page load, then reverts back to the screenshot
silence
Well-known member
Sent!
pegasus
Well-known member
I can't find a logical reason why Firefox is doing this. It might be a bug in Gecko. But you can work-around it for recent versions of Firefox by editing the template "vw_popup.css". At the end of the template, add this:
Code:
@supports (display: flex) {
.vw-popuproot .vw-popupctrl {
display: inline-flex;
}
}
pegasus
Well-known member
There is a conflict with an add-on you have called "GreenText." It looks like it is designed to double-encode HTML in various situations (once in the parent, then again in itself); I don't really understand that. I have modified the execution order of VaultWiki so that VaultWiki occurs later in the chain and can have the final say on what gets encoded.
