Issue: Use XF attachment system to store images

As was discussed in this blog 3 and a half years ago, we purposely moved away from using existing attachment systems because of limitations in those systems. It was not simply a byproduct of having a separate content-type. In both vBulletin and XenForo, we could have added attachments for the new content type under their existing systems.

The main problem with forum attachments as a system was that (under vBulletin anyway) a user retains ownership of files he/she uploads. That means that in a wiki, another user cannot modify the attachment at all (and can't remove the attachment from pages where it is used), without uploading a different attachment in a different location. vBulletin's handling of the ATTACH BB-Code is also terrible. No user can be bothered to keep track of file ID numbers.

In XenForo, it seems it may have been possible to workaround the ownership issue if we put up with awful ATTACH BB-Codes. However, a major feature of VaultWiki 4 is the ability to track changes to attachments, so that if a user removes one from a page, it can be reattached by reverting edits. Or even moreso, if a user uploads a completely different file in place of it (after solving the ownership issue, of course), that you can recover the original file if you need to.

Using standard forum attachment systems, this is not possible without some serious changes to the implementation of the system (but, eventually, still possible). The problem arises when you proceed to add management tools for these improvements that make the attachment system worthy of wiki usage. The management tools require their own separate interface, and arguably with the added interface you have just created a different system and are now just storing records in the same database table or file folder.

Sadly, no we are not going to remove these improvements for the convenience of a shared interface. As far as uploading within the editor, I really don't know how a user would be able to tell that it is one system versus another, aside from that clicking a different editor button opens a different editor pop-up. Even if a forum system were used, this pop-up would still be used to make finding and selecting attachments easier, rather than the inferior vB image selector and one that I don't even think XenForo has.

I'll explain the problem that I want to resolve:

We have experienced a lot of difficulties with images in our wiki, because our members collect images themselves (in their vb profile albums, or photopost gallery or vb attachments), or they use someone else their image (in their vb profile albums, photopost gallery or vb attachments), or they insert a linked image to another website.
This is a massive mess and very confusing to our members. To add to the confusion we try to block members from posting links to image upload websites.

With our move to xf + xmg all of the above is reduced to one system only: profile albums, gallery, attachments are all one system. External images will need to be automatically downloaded from the external site to the xf attachment system. This means that if members want to insert an existing image to their post (forum, blog, groups, widget, resource, etc) then they can simply use a function in the editor to browse through gallery and attachments. This function be available in VW as well because it resolve all the confusion.

The main advantage of VW above wikimedia is that VW offers are more simple writer/editor experience. If that means we need to work with attach bbcode then that is less awful than have separate systems again.

What do you think about the problem at hand and possible solutions?

From what I can see in the product description for XMG, it is actually a separate system from XF attachments, and that XF attachments work in addition to XMG. XMG is a global gallery, while regular attachments allow users to have their own private files (this is a feature they are working on for XMG to totally replace regular attachments).

For this reason, I don't see how rewriting the entire attachment system to accomodate the XF attachment system (which by the way, reintroduces the wiki use problems I discussed above) would help you if you are intending a full XMG solution. XMG is a third-party (paid) add-on, and there is absolutely no way we are going to require a third-party paid add-on as a dependency for VaultWiki.

As far as I'm aware, you should be able to use XMG in wiki pages, so long as the editor button is there. Once private galleries are added to it, you might want to request an add-on to VaultWiki that prevents private images from being used in public contributions, as this causes problems when other users want to edit the same page.

XMG stores XMG images in XF attachment format and XF attachment type. I will ask about the specifics: http://xenmediagallery.com/threads/h...513/#post-2757

If its possible to use XMG in wiki pages with an editor button then that works for me.

It would be nice though to have one main setting to completely disable VW attachments.

Here is the answer:

If XMG is sufficient for your purposes, then please don't hesitate to use it. For your request to easily disable the wiki attachment system, I've created this more inclusive issue: https://www.vaultwiki.org/issues/3420/

Even if the XMG case shows that it's possible to store attachments as user-agnostic in XenForo using a custom AttachmentHandler, physically storing the attachment in XenForo's tables is not ideal for VaultWiki because of attachment versioning, which XenForo itself does not provide. It doesn't make sense to store each version of a wiki attachment as a separate XenForo attachment. From a development standpoint, it will make things run very inefficiently IF it's even possible at all to achieve without cluttering XMG or other interfaces. It also doesn't make sense to take the NuWiki/VaultWiki 3 approach of versioning by keeping one attachment that updates with each version, as this leads to duplicate database entries and is easy to desynchronize. And as I mentioned before, managing the attachment versions still requires a separate interface.

We are likely in the future to make attachment entries in areas list more like XMG categories, with thumbnails and such, but we have yet to implement list filtering and sorting. We have always liked mods like these - in particular there was one iteration of LDM for vBulletin that we liked a lot and tried locally to integrate with NuWiki. Hopefully we achieve something like that with VaultWiki 4.