• This is a demo site for the purposes of showing and testing VaultWiki in a XenForo environment. If you have real questions or need support, please visit the real VaultWiki web site here: https://www.vaultwiki.org

VaultWiki4

Which additional forum platforms should be supported first?

  • Total voters
    39
Pegasus may I ask inquiry a question. I know you where rocking back and forth about choosing which platform you will release VaultWiki 4 for. Has the choice been made?
 
[video=youtube;XeB7lYpzTVg]http://www.youtube.com/watch?v=XeB7lYpzTVg[/video]

Hey guys, I just made this preview video of VaultWiki 4's Admin Panel. Hope you guys like what you see.
 
Many thanks for the video. That looks promising.

Will the language manager allow me to have translations of the same article in various languages?
Will I be able to set a language per area, so that I can organize articles in the same language, in the same area?
 
Hope there will be a IPB connector.. i really miss this in the ipb software.
 
@Alfa1, there is an option to set the Default Language for new pages on a per-area basis, but there is not going to be a way to restrict what languages can be selected in the first release.

This is something we want to do with Prefixes as well - that is, users can only use some prefixes/languages in one area but also depending on the user's permissions. For example, maybe only admins can post articles with the "FAQ" prefix. I'm not sure if permissions like this would make sense for languages, but there should definitely be a way to limit the languages one can post in each area.

This kind of feature is a little complicated and would take some time to work out, so we opted not to include it in the first release.

@ZakRhyno, we will post the final decision in the News section once it's been made. Keep in mind that the decision is merely about which one will be released first. Whatever it is, the other will be coming out very soon after (roughly 1 release).
 
With respect to my previous posts about locking down Prefixes per area, and Languages per area, this has been added for 4.0.0 Alpha 1. After considering it, I don't think there's a need to do separate permissions for it, since it can already inherit the area's permissions - so good organization should be able to achieve that effect if it's desired.

Also, I discussed with Claw Snuff about doing at least another video about other new stuff, and posting them in her blog maybe with more details. Hopefully she has time to do it this week.
 
Hi again, regarding the next video, we just finalized the feature(s) it's going to be about today. However, before we make the video we really need to reset the dev environment to fix the Node History issue since some pre-4.0.0 data we will mention isn't synced up properly without it. As the issue mentions, it should probably take a few days since it's a somewhat Core change.

In the mean time, it's about time for a maintenance release (3.0.17), so hopefully that will be out later on today.
 
Well almost got VaultWiki 4 reinstalled today, but encountered a little catastrophe and need to restart now. Shouldn't be too big a deal since we have backups, but definitely good we caught this bug now and not after release.

Essentially the way pages work now is that they can be regular pages, or they can be assigned a node type like Book or Category. You can also change the assignment at a later date. Say you had a Book, and you wanted it to be a Category instead. You could change the toggle from the edit view of the page, that would remove the Book row and clear all the chapters.

Now wiki Areas are the main containers in the wiki (think forums), and each Area has a specific page associated with it. Well it turns out if you're making changes to the page with the Area type - specifically we were running an upgrade that modified pages in general - you need to be especially careful. If the upgrade process (or potentially a third-party mod) entered the wrong type-ID for the Area page, the page would lose its Area-ness, remove the Area from the database, and in turn remove all its child content (think 100s or 1000s of wiki pages) from the database.

So I had to add a little check to the Page DM: if we forget the type-ID for the Area and it was there before, treat it as though we didn't forget it.

Another day, another bug squashed. Will try the upgrade again with this change on the next shift.

-- EDIT --
Sigh. Now that I think about it, there's a much better way to protect changeable types too. Add add_type and remove_type functions to the Page DM. This way the type can't be "accidentally" removed - it can only happen if remove_type('type') was called before save(). Created a report so I don't forget about this next time I'm in: https://www.vaultwiki.org/issues/2626/
 
Release was delayed due to new bug reports. It seems people get reminded to post them all at once whenever we announce that an update is about to come out. Managed to close most of them earlier today, but still need to fix 1 last compatibility issue with vB 4.1.11 before really releasing it this time (cue mass bug reports).
 
Since VaultWiki 3.0.17 is out now, we're back on track to post some more GUI stuff over the weekend.
 
Will there be demo access to an alpha version of VW4 for licensed members? I think this will spark suggestions. Watching the video prompted me to add new suggestions to the tracker.

Thanks for the video. VW4 seems to be a very big step forward.
 
Yes, there will be demo access to an alpha version once we get all existing features from VaultWiki 3 working correctly, and manage to have a successful upgrade that doesn't involve some type of data loss. On the last test we did, it looks like comments were lost, which is why the VW3/VW4 thread comparison in the video had different posts.
 
You must log in or register to reply here.
Back
Top