VaultWiki4

[Alfa1]

Alfa1, yes prices are low, and we will be increasing prices across the board, but only AFTER VaultWiki 4 is released. And yes, we plan to re-evaluate the size of the development team this year as well.

The prices vbulletin sold and sells addons for: > $199
vbSEO $149
Photopost $129
vbcover >$219
cometchat > $499
Dragonbyte tech >$109
AWC pirate poker $100
IPS official addons cost >$75
Vaultwiki $70

And to top it off:
Searchlight for vbulletin $999 - $1.600
Kayako fusion $999 - 18.000
123Flashchat $199 - $7.500

With such prices its possible to pay for developers.

 

[pegasus]

Currently in upgrade-test pass 3, here's what we're working on now:

Fixed some inheritance issues between page URLs and the URLs of their parent nodes. Uncustomized URLs should inherit the paths of higher level nodes - rather than the default /wiki/Page, it should be /wiki_path_to/Page (e.g. /custom_area_path/sub_area/Page)

Also on this pass I noticed that attachments are being updated and saved to the database, rather than staying in the filesystem if they were in the filesystem before. Fixing this requires adding an extra step to the upgrade that prompts admins to create a wiki-attachments folder before continuing. If they don't create one, database storage will be used.

 

[Alan_SP]

We are currently in the process of combining a feature from VaultWiki 3 that's redundant with a new one. Forum headers are used by some, but we will soon be adding a way to push more than just header-pages to other parts of your site. Thus, we are removing header functionality as it currently exists. The new Content Integration Manager will be much more powerful (use full articles as headers, or other wiki components).

I'm using headers and found them very useful and I'll like to have thread headers. I hope I wouldn't lost them, only have more options and control over header content and possibility to have them in more places (maybe even in profiles).

Anyway, I hope you'll keep headers functionality in some form or other, but as it is now it's excellent and very useful.

And yes, I certainly hope that I wouldn't loose information already in headers?

 

[pegasus]

Your existing headers will be kept, but they will be managed through a content integration manager. Headers aren't a separate page-type any more; you can add any page in the header position.

The changes also make it possible to add headers to other places. However, since the header position needs to be coded for each location, you will be seeing some locations before others.

From a technical point of view, for thread-headers to work in general:

1. You first would need to add a node-type for the location you want, so you would probably need a "Thread" node-type.
2. When someone is reading the thread, you would need a plugin that checks for content-integration for the "Thread" node-type with the current thread ID.
3. Cycle through any results that have position "header", and fetch the items they reference.
4. If the user has permission to view the items, render them as blocks, and place them at the appropriate position in the thread output.
5. To make changes to the headers or create new ones, you need to add controls to modify wiki content in the thread output. You probably want to give this permission to whoever has ownership of the thread-node (the thread creator).
6. In this example, once this is in place, you should be able to add wiki content to any non-wiki page that has node-type "Thread".

 

[stev]

Can we please have an update?

I still think that VW should be priced higher, as well as the BFO should. There should be paid addons to VW as well.
You should be able to pay 1-2 full time devs from the income. This should especially be possible considering that VW is going to open up to XF and IPB. Customers are waiting and unlike with vbulletin; your product can be advertised on both marketplaces.

More and more people are moving away from vbulletin towards IPB and XF. This must have had a significant impact on VW sales. Both platform have a large demand for a native wiki. This demand will be filled by someone else if VW does not arrive within a reasonable time frame. Initiatives like XenCarta are developing on XF.

The prices vbulletin sold and sells addons for: > $199
vbSEO $149
Photopost $129
vbcover >$219
cometchat > $499
Dragonbyte tech >$109
AWC pirate poker $100
IPS official addons cost >$75
Vaultwiki $70

And to top it off:
Searchlight for vbulletin $999 - $1.600
Kayako fusion $999 - 18.000
123Flashchat $199 - $7.500

With such prices its possible to pay for developers.

I totally agree the price for VaultWiki should be higher to reflect its features. Too cheap of a price plus a somewhat stiff learning curve for VW3 is not a good combination.

Perhaps a (low price) lite version with limited features and a (full price) pro version?

 

[Alan_SP]

Your existing headers will be kept, but they will be managed through a content integration manager. Headers aren't a separate page-type any more; you can add any page in the header position.

The changes also make it possible to add headers to other places. However, since the header position needs to be coded for each location, you will be seeing some locations before others.

1. To make changes to the headers or create new ones, you need to add controls to modify wiki content in the thread output. You probably want to give this permission to whoever has ownership of the thread-node (the thread creator).
2. In this example, once this is in place, you should be able to add wiki content to any non-wiki page that has node-type "Thread".

Ok, the most important thing is that I still could use headers, old headers will be kept and that there could be more places where I could have headers.

I didn't understand all this talk about creating headers (what nodes are etc), but I think you are saying that I could for example could have headers for user profiles, blogs, CMS articles etc? How we could control who can see this headers? In some situations I would want that everyone could see them, but only some could create/edit them. And of course, that sometimes only some could see them.

When talking about that, would be possible to have two (or more) types of header per object? When I say object, I mean for example threads, user profiles etc. If it would be possible, I could create public header that will be visible to everyone and private visible only to moderators. Or editable by anyone and "official" editable only by moderators.

This would be really great, having this option to create more than one header type with different permissions.

Also, ability that thread creators can control thread header is also great. Now I use mod that makes first post editable forever by thread creator and this is even more useful as thread header would be visible on every page (similar like first post on vborg).

 

[Alan_SP]

I totally agree the price for VaultWiki should be higher to reflect its features. Too cheap of a price plus a somewhat stiff learning curve for VW3 is not a good combination.

Perhaps a (low price) lite version with limted features and a (full price) pro version?

I don't think that VW has steep learning curve, when you set some things up (and there aren't too many things to set up) it works pretty simple.

Maybe if only there is more examples for what and how we could use some options, this would be better. There are many options I don't use (categories, books for example) because at the moment I don't know for what I would use them.

Headers also was unused for long time, but then I discovered how useful they are. Headers are really excellent and if new headers would enable many places to place them, having more than one header with different permissions, this would made them most useful besides wiki part.

I suggest that in manual are also usage possibilities, for what something is good for (and you could ask us, customers, for what we use it), what we could have with certain parts of VW. When people know what they could use VW for, they would want it much more. This of course would generate more sale. But people should know for what they could use it. Now people think that VW is just wiki, but it is much more and could be used in much more ways.

Lite version should have only basic wiki, just to let people see how it looks like, and full product (only one version, as it is much more difficult to have more versions as Pegasus already said) could have it all. For price, maybe two options, lower price up front ($100), but having higher annual renewal cost for new versions ($50) or need to purchase new versions, and higher price up front, with lower annual renewal (or completely without it).

But, I'm thinking, the biggest problem is having money at first. If some site is successful it's easy to pay for modifications later in site's life then in the beginning. So, it may be could strategy to have lower price up front, but with need to buy all new versions and higher price up front that entitles you for all new versions. Of course, support should be paid annually for. Higher price could include lower annual support price.

Not sure how would look like best business strategy, but I know that at the beginning it's much harder to pay for something and people need to know for what they could use it with many examples for practical use. We need to know what we're paying for, why it would make our sites successful, where the value is.

 

[we_are_borg]

Pegasus when are we going to see VW4, its more then a year and still have no idea whats happening, like you said you stopped posting in blogs etc.. Also if i look at the stats your slowing down is everything going as planed or are there problems with development.

 

[pegasus]

As I mentioned earlier in the thread, we are now testing VaultWiki 4 and getting it stable enough for public testing. I have been updating this thread every few days to mention specifically what needs work.

Since my last post, we have fixed the issues with attachments not being saved to the file system, and are scrubbing for other bugs.

E.g. In the last five minutes, I think I see that template pre-parsing (a new technique designed to reduce render time for wiki templates) isn't saving to the database correctly.

 

[pegasus]

Today confirmed that URL routing works properly by checking the forum main-pages sync to their new parent nodes during the upgrade (in VaultWiki 3, pages were linked in this way via URL rather than page ID). There were some challenges getting this to work since the URL format in VaultWiki 3 is not entirely compatible with VaultWiki 4. A VaultWiki 4 URL, by default, contains the parent-node URL, e.g.

If "Page A" is in "Area A", the URL of "Page A" is:
url/of/area_a/page_a

In this way, URLs now fully reflect the directory structure of the wiki.

However, I noticed that editing some existing routable nodes won't successfully save because the URL collides with itself. This is likely due to a recent change in the format of the router's internal processing, which actually returns the full node tree now, rather than only parent-nodes. I will have a closer look tomorrow.

 

[we_are_borg]

Thanks for the updates pegasus. The blogs you made last year where informative and i think most will appreciate it if you post more whats going to change and happening in VW4.

 

[stev]

Currently in upgrade-test pass 3, here's what we're working on now:

Fixed some inheritance issues between page URLs and the URLs of their parent nodes. Uncustomized URLs should inherit the paths of higher level nodes - rather than the default /wiki/Page, it should be /wiki_path_to/Page (e.g. /custom_area_path/sub_area/Page)

Also on this pass I noticed that attachments are being updated and saved to the database, rather than staying in the filesystem if they were in the filesystem before. Fixing this requires adding an extra step to the upgrade that prompts admins to create a wiki-attachments folder before continuing. If they don't create one, database storage will be used.

Hi Pegasus,

What's the advantage of being stored in filesystem vs in database?

 

[stev]

I don't think that VW has steep learning curve, when you set some things up (and there aren't too many things to set up) it works pretty simple.

Maybe if only there is more examples for what and how we could use some options, this would be better. There are many options I don't use (categories, books for example) because at the moment I don't know for what I would use them.

Headers also was unused for long time, but then I discovered how useful they are. Headers are really excellent and if new headers would enable many places to place them, having more than one header with different permissions, this would made them most useful besides wiki part.

I suggest that in manual are also usage possibilities, for what something is good for (and you could ask us, customers, for what we use it), what we could have with certain parts of VW. When people know what they could use VW for, they would want it much more. This of course would generate more sale. But people should know for what they could use it. Now people think that VW is just wiki, but it is much more and could be used in much more ways.

Lite version should have only basic wiki, just to let people see how it looks like, and full product (only one version, as it is much more difficult to have more versions as Pegasus already said) could have it all. For price, maybe two options, lower price up front ($100), but having higher annual renewal cost for new versions ($50) or need to purchase new versions, and higher price up front, with lower annual renewal (or completely without it).

But, I'm thinking, the biggest problem is having money at first. If some site is successful it's easy to pay for modifications later in site's life then in the beginning. So, it may be could strategy to have lower price up front, but with need to buy all new versions and higher price up front that entitles you for all new versions. Of course, support should be paid annually for. Higher price could include lower annual support price.

Not sure how would look like best business strategy, but I know that at the beginning it's much harder to pay for something and people need to know for what they could use it with many examples for practical use. We need to know what we're paying for, why it would make our sites successful, where the value is.

Let's take the issue of inserting pictures into an VW's article as an example: It takes extra effort and many steps to do so, not a straight forward "browse, insert. Done!".

Let's take another issue with turning a forum on and off for VW, at least in my case: I have to reindex said forum for it to be readable, ortherwise users only see blank page.

Even in your case, "Headers also was unused for long time, but then I discovered how useful they are". So it's not easy to discover VW's feautures, is it?

I communicated with Pegasus last year about VW, he did patiently explain to me the nature of a wiki which is in itself not a straight forward process, especially for someone who does not have any knowledge in wiki's process and its terminology.

We use and love VW, and would like it to be as easy as possible.

 

[pegasus]

Hi Pegasus,

What's the advantage of being stored in filesystem vs in database?

In general, it's a good idea to store attachments in the file system when you can.

Attachments in the database quickly rev up the size of the database, which makes it more challenging and take longer to backup and restore, and increases the server overhead that the database uses. At the same time, backing up your forum is also simpler for the database method, because you don't have to go through the trouble of backing up the attachment files too.

Although users are sometimes unaware of this until it's too late, many shared hosts also have limits on the size of the database.

Storing attachments in the file system requires that your system administrator has given PHP permission to write to the file system, and can have some security issues if your admin hasn't set this up properly. However, if you're on a decent shared host or your system admin knows what they are doing as far as server security, this is the option to use.

Also, the transaction between PHP and filesystem is slightly less expensive than PHP and database, since the data doesn't usually need to be streamed over the network when saving or viewing.

 

[stev]

Thanks for your detail answer

 

[dvsDave]

All this talk about the URL structure begs the question, will this be compatible with vbseo ?

 

[pegasus]

Yes, but VaultWiki will (as before) need to be configured to resolve before vBSEO, since vBSEO doesn't know how to read any third-party URLs, and it doesn't have an adequate plugin system for handling them.

 

[pegasus]

After a relatively successful upgrade this time, I've noticed that Social Group Pages were not imported to VaultWiki 4. So that's what I'm fixing for the next day or two.

 

[Alfa1]

Do you plan to add XF support first or IPB?

 

[pegasus]

I've gone ahead and added a poll to this thread. I'd encourage all users who are looking forward to one or the other to vote. If you already know people in either community who are interested in VaultWiki, please invite them to vote as well, so we get a better sense of which one more people are waiting for. The poll will be closed manually when we open up VaultWiki 4 for public testing.

We've been getting requests for one or the other privately, but it seems like there's nearly an even amount. Plus, a public poll might help users understand how we arrive at our ultimate decision.

We already hold licenses for both products, so this is not an issue.