VaultWiki [Paid] 4.1.7 Patch Level 1

[pegasus]

also it doesn't use the xenforo editor, so it makes that look out of place also.

It actually does use the XenForo editor. We don't do any special styling to it, so it shouldn't look different either. What is it that makes you think otherwise? Does the editor not load (i.e. blank text-box)?

Also, do you plan on having the administration panel more integrated with xenforo?

This is something that's bothered us for a while. The Admin Panel was developed first, before any other part of the core or anything, and it was developed with vBulletin in mind, which loads it in a frame. There is really no problem under vBulletin aside from having a different style, because it loads in a frame and you still have access to the main admin menu.

We opted to have a separate area simply because there are so many panel pages that the built-in navigation started getting cluttered, and vBulletin didn't support tabbing or grouping the panels in a sensible way using the standard navigation, without reintroducing a problem discussed in the next paragraph. XenForo does support tabbing however (Applications, Users, Appearance, etc), so it's possible to put the navigation back in the admin sidebar as XenForo admins are used to without worrying about cluttering any particular tab with 20 new options (by having it under an admin "Wiki" tab). Still, this change has been considered more of a nice-to-have feature, so it was been delayed while we made our way to a stable release and added more fan-favorite features first.

As for grouping permissions and such in the panel rather than the normal permissions area. This might work for some individual toggles but I'm not sure how many permissions we would want to move back. Under VaultWiki 3 we had all of VaultWiki's panels merged with their related vBulletin admin pages, like the usergroup edit page. However, users thought it was a mess and found it difficult to find specific options when they were all blended like that. Continuing with the permissions example, they knew they were looking for wiki-related options, and despite there being a completed manual explaining what options were where, we would still get messages daily asking how to do something simple like change the permissions. We would tell them it's under the normal usergroup edit page, and they still couldn't find it, usually because the page was so long from other add-ons they had already.

 

[Jake B.]

It actually does use the XenForo editor. We don't do any special styling to it, so it shouldn't look different either. What is it that makes you think otherwise? Does the editor not load (i.e. blank text-box)?

Yeah, when I installed it on my test board it was just a normal textarea. Honestly, didn't really look into what was causing this as I just assumed that it was how you made it.

This is something that's bothered us for a while. The Admin Panel was developed first, before any other part of the core or anything, and it was developed with vBulletin in mind, which loads it in a frame. There is really no problem under vBulletin aside from having a different style, because it loads in a frame and you still have access to the main admin menu.

That does make sense, I forgot about vBulletin using the iFrame for the admin panel. It's been a while since I used it (Never renewed my license after 3.8.5)

As for grouping permissions and such in the panel rather than the normal permissions area. This might work for some individual toggles but I'm not sure how many permissions we would want to move back. Under VaultWiki 3 we had all of VaultWiki's panels merged with their related vBulletin admin pages, like the usergroup edit page. However, users thought it was a mess and found it difficult to find specific options when they were all blended like that. Continuing with the permissions example, they knew they were looking for wiki-related options, and despite there being a completed manual explaining what options were where, we would still get messages daily asking how to do something simple like change the permissions. We would tell them it's under the normal usergroup edit page, and they still couldn't find it, usually because the page was so long from other add-ons they had already.

Does it use the normal XenForo permission entries, or custom ones made for it? I do prefer to have all of my permissions in a single location.

Also, something I forgot to mention in my previous post is the splash page you have when you edit a page, perhaps just use the XenForo AutoValidate to validate entries (and display a modal if there are errors) and then use the ResponseRedirect to redirect to the edited page with a message that says it was edited, instead of a completely separate page for that. Just small things like that make it not have that "XenForo feel" and makes it seem out of place, but then again I may just be nit-picking

 

[pegasus]

Does it use the normal XenForo permission entries, or custom ones made for it? I do prefer to have all of my permissions in a single location.

It's a separate permissions system entirely. The way permissions stack when customized for different wiki areas and individual pages doesn't lend it to being stored with other permissions. Also a lot of permissions are generated dynamically based on other setting values, versus the XenForo method of loading them with a static XML file.

For the users who want all the wiki stuff in one spot vs the users who want all the options of a certain kind (e.g. permissions) in one spot, I think maybe a happy medium would be to put shortcuts around the XenForo CP. For example, under Users > Permissions, add a Wiki Permissions shortcut.

Also, something I forgot to mention in my previous post is the splash page you have when you edit a page, perhaps just use the XenForo AutoValidate to validate entries (and display a modal if there are errors) and then use the ResponseRedirect to redirect to the edited page with a message that says it was edited

I suppose you're referring to the "Thanks for editing..." message. I would be open to condensing this. We have to consider though that a lot of sites like to have extremely long wiki pages (I can think of 1 client in particular that makes them as long as possible before the server starts timing out and then scales them back from there - they have several articles that are over 300,000 characters long, and a bunch of comments to render for each page). The ResponseRedirect occurs in the same page load, so perhaps we should check the timings first, and if we think the page will time-out soon, do the hard redirect instead.

For the AutoValidate idea, that sounds like it could be nice, and I understand the "XenForo feel" of it. However, I feel like error messages should be persistent so that the user can refer to them as needed, especially when there are multiple errors. This has been an aspect that has saddened me for a while about XenForo's validation methods. That popup message that disappears after a single click doesn't really do it for me. I find myself often resubmitting with the same errors just to read it back a second time.

 

[Jake B.]

For the AutoValidate idea, that sounds like it could be nice, and I understand the "XenForo feel" of it. However, I feel like error messages should be persistent so that the user can refer to them as needed, especially when there are multiple errors. This has been an aspect that has saddened me for a while about XenForo's validation methods. That popup message that disappears after a single click doesn't really do it for me. I find myself often resubmitting with the same errors just to read it back a second time.

They are, it will place the error next to the field that caused the error as well

 

[pegasus]

Yeah, when I installed it on my test board it was just a normal textarea. Honestly, didn't really look into what was causing this as I just assumed that it was how you made it.

You probably only tried to edit the main landing page. The landing page has separate settings to allow BB-Code, HTML, etc (you can also set these for each area). If BB-Code is disabled, there's no point of the standard editor, so we tell the toolbar to hide. After reviewing your message for a while, I discovered that the default value for BB-Code on the index was not being loaded upon installation, and that it had to be set manually. This will be fixed in RC 4 (for new installs only; existing installs would still have to change the setting manually, else we risk modifying existing setting values an admin might actually intend).

 

[pegasus]

Posted this on Twitter moments ago:

While debugging our @MediaWiki importer, we discovered that upgrades from Lite left users in non-upgraded state. Users who upgraded from VaultWiki Lite during RC should contact support for a data integrity review.

We are currently working on an alternate upgrade path to resolve affected installations without performing a re-install.

 

[pegasus]

pegasus updated VaultWiki with a new update entry:

Changes in 4.0.0 RC 4

(released October 26, 2014)

• Import Content from MediaWiki
• Display View Counter on Wiki Pages
• Allow Custom Discussions with Main Discussion Disabled
• last update info in lists shows title of last updated content
• reference to the previous revision is tracked for each revision
• improved performance slightly
• Fixed Mediawiki syntax not working when enabled
• Fixed missing phrases for install/upgrade steps
• Fixed users still auto-subscribing when subscriptions are...

Read the rest of this update entry...

 

[Walter]

Can I see any real/live site using it with Xenforo? Gladly via private conversation.

 

[pegasus]

pegasus updated VaultWiki with a new update entry:

Changes in 4.0.0 RC 4 Patch Level 1

(Released October 30, 2014)

• Fixed deferred.php DDoS vector
• See: https://www.vaultwiki.org/articles/160/

Also: 4.0.0 RC 3 Patch Level 2, 4.0.0 RC 2 Patch Level 2, 4.0.0 RC 1 Patch Level 2

Read the rest of this update entry...

 

[eagle eyes]

Would like to know how stable this is? Also a demo would be fine rather than a demo that crashes and gives bad impression.

 

[pegasus]

a demo would be fine rather than a demo that crashes and gives bad impression

If the demo crashes for you, please report the crash so it can be looked into. If no one reports an issue, no one knows about it.

Except for 2 minor features that don't exist but were expected by users of old VaultWiki 3.x versions, there are no known confirmed bugs in VaultWiki 4 at this time.

 

[pegasus]

I have fixed the issue with installing VaultWiki in the latest version.

My add-on LOVES to see an upload directory. If it sees an upload directory, as is common with most XF add-ons, it knows the intention is to upload the contents of the upload directory to the root of XenForo.

That's all good until it finds ANOTHER one several directories deeper...

In the next version, I have changed the behaviour so that duplicate folder names are ignored, so only the first folder it finds that is allowed is used.

@Chris D has worked out the issue installing VaultWiki via his Add-on Installer in the next release of his add-on.
@eagle eyes, if this was the "crash" you were referring to, please let me know. If not, please let me know what else we need to look into.

 

[pegasus]

Although arguably a useful function of VaultWiki, I've added information about its external callback in the Additional Requirements section:

"This add-on performs an external callback to a VaultWiki-operated server once per day to check for add-on updates, which are then displayed in the Admin Panel."

 

[Deleted member 10469]

Hello, it's possible to have an online demo version with admin panel for try please ?
Thanks.

 

[Walter]

Can I see any real/live site using it with Xenforo? Gladly via private conversation.

?

 

[pegasus]

Due to our privacy policy, we're not allowed to simply list sites that are using VaultWiki. On the other hand, I'm hoping one or two will chime in, as I can think of a few that are using RC 4 quite well on XenForo that would be really great examples to prospective users.

 

[Alpha1]

a list of vaultwiki sites is something that is requested frequently.
it would be worthwhile to add a link directory to your site. it would increase your sales.
you can use xenreviews or showcase for this. I am sure that webmasters would be happy to advertise their sites on your directory.

 

[pegasus]

pegasus updated VaultWiki with a new update entry:

Changes in 4.0.0 RC 5

(released November 25, 2014)

• Merge Wiki Admin Panel into XenForo Admin Control Panel
• Show Reported Wiki Content in XenForo Report Center
• Show Moderated Wiki Content in XenForo Moderation Queue
• Use Admin Search to Find Wiki Admin Creations
• Customize Sidebar Blocks per Area and for Index
• Customize Discussion Topics for Index
• Global Toggle for User-Created Discussions
• More user-friendly prefix display
• Fixed conflict with Nodes as Tabs makes a slow wiki
• Fixed...

Read the rest of this update entry...

 

[pegasus]

@Jake B. the new version of VaultWiki merges the Admin Panel to the XenForo ACP, the Report Center, the Moderation Queue... Still have to deal with the reload splash and pop-up modals that you mentioned, but I think it's already a big step forward (despite that I liked the old Admin Panel better ).

 

[jOOc]

@pegasus can you add some pictures of the latest release including the admin panels in ACP.