Vaultwiki for Xenforo

[Deepmartini]

Is this for articles? Is this a CMS? I am trying to figure out the difference with a wiki and a cms?

 

[craigiri]

Is this for articles? Is this a CMS? I am trying to figure out the difference with a wiki and a cms?

Just names, really!

Both can be used for "content management", so they qualify.

CMS is just a made-up term....in general it started out describing systems used by major media like the NYT in order to manage their digital content across many authors and locations.

 

[Jaxel]

Wikis are usually open for editing by unlimited users... a CMS is usually only open for editing by assigned editors.

 

[pegasus]

Just curious if this is an already-reported issue for XenForo... I feel like there should be a scrollbar or something.

Or if there's a way to group hover states with their original properties (i.e. have more than 1 background or text property per group, without extending the "Settings" group), that would be ideal.

 

[Alpha1]

That may be a bug. If so then this should be reported in the bugs forum.
http://xenforo.com/community/forums/bugs/

 

[pegasus]

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.

 

[Blackbeard]

Can wait to see it in the final product!

 

[The Dark Wizard]

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

Any progress ?

 

[pegasus]

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.

 

[The Dark Wizard]

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.

Just keep us posted !

 

[pegasus]

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.

 

[The Dark Wizard]

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.

Neat.

Are we still on for a Q2 release?

 

[pegasus]

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.

 

[The Dark Wizard]

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.

Glad your liking the way xF does things !

 

[pegasus]

Close of day today... custom BB-Code callbacks are working again, at least in wiki comments, and they are performing recursion as expected (e.g. if you bold-face something inside a link). Have to make some updates to WYSIWYG, because XenForo keeps trying to convert the 'WIKI' BB-Code to the 'URL' tag when the RTE is open by default.

 

[pegasus]

So while paying close attention to the display of the wiki comments and the controls for editing, reporting, etc, I ended up making some changes to VaultWiki's permissions system, and made another observation.

VaultWiki currently uses a Yes>No>NotSet/Inherit precedence for permissions, and applies warnings simply by changing the formula at the appropriate time to No>Yes>NotSet/Inherit. However, XenForo doesn't use a negative Warnings (Infractions) system like vBulletin does. Thus it is impossible to disallow permissions due to infractions under XenForo with the current design. In order to allow for this, a modification to VaultWiki's permissions system needs to be made so that, like XenForo, there is a "Never" variation of "No" that takes precedence over "Yes".

Unfortunately this means adding a third state to the system which we had hoped to avoid. It will also mean an hour or two of development tomorrow to make the change to the required locations.

Nevertheless, I do like that the permissions applied through a Warning can be understood more logically in XenForo because "Never" exists.

 

[pegasus]

So while trying to debug attachments, I discovered that XenForo was broken under PHP 5.4. Luckily the devs recently released 1.1.4 which fixed the plethora of issues we were having.

However, performing that upgrade showed us another problem: code-event listeners are not executed during XenForo upgrades. This resulted in the style for VaultWiki being broken until another style rebuild was executed through the ACP.

This is not something we want to tell our users: "Every time you run the XenForo upgrade script, you need to run the VaultWiki upgrade script after it." The problem is that VaultWiki uses a large number of environment variables (and variants of existing Style Properties) that are stored in fake Style Properties so they have a nice @shorthand and don't need to be registered as template parameters. Even though they don't actually exist, we were able to get them rebuilt into the style information with some clever listener placement. But since listeners aren't executed during the upgrade style-rebuild...

This puts us in a bit of a quandry:
We could try to figure out a way to detect whether an upgrade was just run, and if so perform an extra rebuild.
Or we could create another template helper which would completely destroy the niceties of the @shorthand. @propertyName versus {xen:helper vw-property, 'propertyName'}
Or we could register them as _defaultTemplateParams with some clever I-don't-know-why-it's-possible Dependencies overriding. {$vw_property.propertyName} versus {xen:helper vw-property, 'propertyName'}

What I would really like is if the template compiler accepted any form of @word as a possible Style Property, sent it to the Style Property handler. Then on-render, output the property value if it exists; if it doesn't, output '@word' as a literal string. Since I don't see a reason why this wouldn't happen in the future of XenForo, I'm inclined to go with the first option of detecting recent upgrades.

 

[The Dark Wizard]

What ever you think is best !

 

[Jaxel]

This thread should be moved to here btw:
http://xenforo.com/community/forums/resource-and-add-on-discussions.63/

 

[pegasus]

Resolved all that finally, and I just realized we can't test attachments on our locked-down dev site anyway. Flash doesn't like maintaining cookies or something so the uploads always fail (error #2038). We'll have to test other things and wait until we take XenForo live to try attachments. Like: http://xenforo.com/community/threads/period-after-style-property-breaks-it.48443/

I guess it's time to try to actually make some wiki pages.