There are no known conflicts between the latest version of BbCodes & Buttons Manager and the latest version of VaultWiki.Is vautwiki compatible with "BbCodes & Buttons Manager" ?
Okay, so then do I report this here to you or to "BbCodes & Buttons Manager?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.
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.Okay, so then do I report this here to you or to "BbCodes & Buttons Manager?
if (
!vw_Hard_Core::model('Tag')->parse_for($tag, $for) OR
!vw_Hard_Core::model('Tag')->check_field($tag, $prefix . '_editor')
)
{
continue;
}
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;
}
Worked like a charm, thank you!To fix "Show in wiki/non-wiki editor" not having any effect, edit library/vw/XenForo/ViewPublic/Helper/Editor.php. Find:
Replace with:Code:if ( !vw_Hard_Core::model('Tag')->parse_for($tag, $for) OR !vw_Hard_Core::model('Tag')->check_field($tag, $prefix . '_editor') ) { continue; }
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') ) { unset($options['json']['bbCodes']["$tag"]); continue; }
I cannot reproduce the problem with the arrows. What browser are you using?
It fixes it for the first page load, then reverts back to the screenshotI 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).
Sent!I would recommend that you open a ticket request at the support site in the Members area, under Services. There is either a bug here that I can't reproduce or you have mixed file versions on your server which is not safe.
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:Also the tab navigation arrows are off the tabs in both the default and custom styles.
@supports (display: flex) {
.vw-popuproot .vw-popupctrl {
display: inline-flex;
}
}
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.However, my pages are being rendered in raw HTML, and I'm not sure why.
View attachment 118654
We use essential cookies to make this site work, and optional cookies to enhance your experience.