Deepmartini
Well-known member
Is this for articles? Is this a CMS? I am trying to figure out the difference with a wiki and a cms?
Is this for articles? Is this a CMS? I am trying to figure out the difference with a wiki and a cms?
Posted a report here: http://xenforo.com/community/threads/style-property-groups-extend-past-admin-footer.47108/
But I ended up breaking it up into 5 groups anyway (Wiki Pages, Wiki BB-Codes, Wiki Page Controls, Wiki Forms & Controls, Wiki Sidebar). Just figured once I saw I was creating so many I would see what happens when I get to the bottom of the page. Conclusion: it continues past the end of the page.
On a slightly different note, added a new Style Property type today (Shadow). That was fun. Unfortunately it uses the Settings tab, but I wasn't in the mood to make admin-template injections.
View attachment 42788
Just keep us posted !Every day more and more of VaultWiki loads under XenForo without showstops. An interesting fact: VaultWiki 4 has been available for vBulletin for a number of weeks now, but the first wiki content to be successfully deleted was running the yet-unreleased XenForo dev.
In VaultWiki 4, we let admins turn on/off HTML, BB-Codes, etc and users have permissions for such things when they post comments. I've been trying to get this working properly under XenForo now that I can make posts without stop errors, and as far as I can tell, there's no built-in mechanism in XenForo itself for most of these features. That wasn't such a big deal to fix, but in doing so I noticed major architectural differences in the design of XenForo's BB-Code parser versus vBulletin's.
XenForo uses a recursive parser, whereas vBulletin (below version 5 anyway) uses what I might call a "progressive" option. In my opinion, a recursive approach is much better since it's less likely for collisions to occur when the code execution is nested the same way as the BB-Code.
However, I realize now that the current design of VaultWiki 4's parser (and roughly all of the custom BB-Code handlers) won't be able to work with both. We will have to write a second version of the parser for platforms like XenForo that use this alternate approach. While this is added development and potential code duplication that we wanted to avoid as much as possible, XenForo's recursive approach will allow the wiki parser to be far less convoluted and far more efficient than it is under vBulletin.
I realized after my previous post that a lot of the existing parser can be saved (specifically, the callbacks) by updating them to expect that they may be called upon to perform recursion. In this case, it's not so much work to delay a Q2 release. Yesterday I extended XenForo's parser to handle the disabled features and permissions and it went very smoothly. I have to do that maybe a total of 3 or 4 more times for things like syntax conversions during imports and WYSIWYG.
The design of XenForo's parser is very intuitive and there are rarely any surprises in the output. While vBulletin required us to create many variations of the same parser that run sequentially and try to manage collisions and double-encoding and other things, the same can be accomplished in XenForo without any of that extra code, using a single instance of the (extended, but otherwise) stock parser.
We use essential cookies to make this site work, and optional cookies to enhance your experience.