Issue: Ability to Disable Certain Page Types Completely

Everything is setup in the backend to remove features for disabled types. Disabling via config file, it seems to be working properly. Just need to add an admin interface to make disabling them a simple task.

Implemented in the Next Release. If you notice any features active that shouldn't be active once a type is disabled, please open a bug report.

How can I disable the attachment system?
Or how can I disable the creation of attachment pages?
Please add the answer to the vaultwiki manual. (once you get it working again)

In VaultWiki's Admin Panel, go to Structures > Content Types. You should be able to disable attachments there.
This will disable the entire attachments system, and even existing attachments will be broken.
If you want to just prevent new attachments from being posted, you can:
- Remove "Attachments" from the list of acceptable content-types for every area
- Revoke or set "Never" to the permission "Can post new attachments?" for all groups. If you use "Never", you should not have to modify any customizations or user masks.

The handling of attachments in VW4 is a good reason not to upgrade from VW3.
Upgrading or importing the wiki will create a mass of image pages. There should be a way to turn this off. I do not see any use of such pages and VW will create hundreds or thousands on import. This is not only a problem for usability but also for SEO. I do not want a mass of low quality pages on my website. My site has top rank in Google and I do not want to loose millions of monthly visitors.
At the same time I also do not want to loose my wiki images.
The only solution seems to stick to VW3. Please advise if you see another solution.

I do see the value of having a wiki image, because that can in the future allow us to use the thumb in other places. But the image pages I do not want.

Your above solutions do not prevent VW from creating wiki pages on import and upgrade. Permissions are not a good approach. There should be a main switch to turn the wiki attachment system on or off globally. There should also be a switch to turn off the creation of attachment pages.

Since Gamma 4, auto-created pages like attachments are added to a hidden area called the "System" area, rather than to whatever area the importer created first. By default, the contents of the System area are not crawled or visible to wiki visitors. But it is used to store data that has nowhere else to go. An example of this is imported non-wiki attachments. This change has resolved most of your complaint.

VaultWiki 4 imports existing attachments from VaultWiki 3 as wiki attachments, because vBulletin's (and even XenForo's) attachment systems have been plagued with a major design flaw: they are locked to a specific user and are identified in BB-Code by a human unfriendly attachment ID number. Because of this, VaultWiki 3 had issues where when different users would edit a page that contained an attachment, sometimes the attachments the previous user had uploaded would get lost or stop working, or the user would be unable to submit edits at all. If someone needed to fix a broken image, sometimes they had no idea what it was before, because it just looked like [ ATTACH ] 15684956 [/ ATTACH ]

This was not directly a VaultWiki issue, but an issue of trying to combine multiple-authorship with existing forum functionality that could not support it. We advised users in countless threads and posts and bug reports (and here I am repeating it all once again) not to use the ATTACH BB-Code and to use IMG instead, if they didn't want to use the wiki's attachment system for certain things. We advised users that there was no way to "fix" vBulletin's attachments, and that eventually we would have to implement a completely new system.

That happened in VaultWiki 4. VaultWiki 4 cannot maintain the original attachments because they are locked to the original specific post ID. We expect many users will delete their old wiki forums after upgrading to VaultWiki 4. If that were done, then the original attachment would be removed too. That is just the way vBulletin 3's attachment system is designed. vBulletin 4 and XenForo would handle it a little better but still be victim to the multiple-authorship conflicts.

The attachment system we have now is designed to resolve that situation. If you think it promotes a loss of page quality for SEO, then by all means, suggest an option to opt images or other page types in/out of search crawling, as we are doing for entire areas (https://www.vaultwiki.org/issues/3792/). But as we warned for years ahead of time, we no longer support using forum-system attachments in wiki pages, because they simply don't work reliably and can't be made to work.

It may seem odd at first when you are used to the other way, but having a "page" for each attachment is very useful. For example, the uploader can add a description for the picture is so others know how it should be used; sometimes a filename isn't good enough.

Thanks for the elaboration. I have some questions and critique to the approach.
In vbulletin + VW3 there are several ways to add an image to a wiki:
1. include an attachment by link within img bb code
2. include an attachment by attach bb code
3. include an vb profile album image by img bb code
4. include a vb post image by img bb code
5. include an photopost image by img bb code (in case such gallery is installed)

So which of the above methods for wiki images are imported into VW wiki images?

I think its a good decision to import images into the wiki system.
But the mandatory creation of wiki image pages is not a good decision.
wikipedia adds this extra page to include more SEO optimization into the page and the site structure. Simply adding a superfluous page is not a good idea.
I get quite a bit traffic from Google images, so I do not want to hide my images from guests.
I just want my wiki images to be accessible in 2 steps:
wiki article > image file

not the current 3 steps:
wiki article > superfluous image page > image file

Can you please implement a function to let me do that?

EXIF data and file name can also be used to store information if needed.
I already have an image gallery and one of the reasons for migrating to xenforo is that I no longer have to have 2 image galleries.

Of the 5 you mentioned, the only 1 that creates VW image pages is #2. The other 4 are perfectly acceptable and are left alone. If you have already imported these attachments to a different gallery software, that is not something VaultWiki is equipped to translate. However, if you would rather be forced to manually update all the ATTACH tags by hand at the start, rather than use the wiki attachment system for only those images, then perhaps we can add an option to the importer to NOT convert ATTACH tags and NOT to import attached files.

When I mention that the System area is not crawled or visible to guests, I don't mean that the contents aren't accessible. Just that the System area itself doesn't show up in your area list on the wiki index. For the contents not being crawled, I mean that it uses the robots header/meta tag to control whether a page or attachment is indexed by a search engine or not. If you want the attachment file to be indexed but not the attachment's info page, then that would just require a setting to handle that situation. But I think that would be a moot point once we implement the policy that if a page has no child pages and has no text, then it won't be indexed anyway. This would handle so-called stubs and empty attachment infos automatically, and would allow descriptions for those attachments to be indexed as well, all without further intervention on your before.

In the current design, you can access the image file in either the 2 steps or 3 steps you mention. It just depends on your implementation of the images. If you think there should be an option to change the default link to the file or to just make it easier to link directly to it, I'm sure that's an option we can consider.

But at the core of it, removing images from being pages altogether would have undesired effects, like making images unsearchable, not listed on special pages, not version-able, affect license management, and more. All this comes from images having "page" as a base class, and jumping directly to the image rather than showing something like "This image is licensed for use only on this web site," or at least providing an interface to add that information, can be a dangerous proposition. That is what the current system is designed to handle.

Again, there is nothing FORCING you to use the wiki attachment system if you have another gallery that you can access with IMG or a similar tag. The only thing you are not allowed to do is use ATTACH tags because they simply aren't compatible.

Number 1 gets imported as well.
I dont think the attach bb code is used much on my site because that only shows a thumb.

It seems to me that its possible to manually process all attachments, because there are 400 attachments imported as image pages. Will be a monks task to go into all those articles and change the links but its possible. This seems the best decision.

Its too bad, because it would be very useful to have a main image for each wiki article. But a page based approach is undesirable and has no apparent benefits for my sites as far as I can see. I see it as a big downside to have the all_pages function cluttered up with images. I see no use for image versioning or licensing. My ToU simply denies all licensing.

When importing from VaultWiki 3:

1. Existing forum-based attachments physically attached to wiki pages are imported as wiki attachments instead. Perhaps this is what you are experiencing. I don't know.
2. A replacement function is run on [ ATTACH (?:=config)? ] (\d+) [/ ATTACH] that appear in wiki page text and those are imported as wiki attachments.

Into vBulletin 4 and XenForo, there should be no other conversion performed with respect to attachments. Attachments on comments are just left alone because comments have a single author and the target system supports attachments for non-post content types. It is possible, though, that there is a bug and this follows the vBulletin 3 behavior. If that's the case, I will need you to confirm by looking at your comments in XenForo and seeing if anything was converted there.

Into vBulletin 3, attachments on comments are also imported as wiki attachments since vBulletin 3 only has native support for attachments on the post content-type.

Image versioning is useful when multiple users are able upload to "the same image." If one of them breaks the file, it's helpful to be able to rollback. This was a constant danger in VaultWiki 3. I'm surprised more users were not affected by it.

I agree with you on the All_pages function. I think this and possibly most Special pages should be updated to be like Statistics -- attachments and templates are not included by default. That is really a simple behaviorial change and can be implemented for any point release. Just requires updating the base Special query and the appropriate style templates (to toggle attachment inclusion if desired).

There are other minor issues that can be corrected over time, but these are all problems are not new to VaultWiki 4. Properly "attached" attachments in VaultWiki 3 followed the same design. They were page-based, too. But before they were not versioned and suffered from authorship conflicts.

Good stuff.

What most of my wiki's contain is not attach bbcode, but imgr bb code, which is basically the same as img bb code but with text wrap and right alignment. This to emulate the main wiki image in infoblock on the right that wikipedia has. Nowhere is attach used.

What has happened is that VW has sort of imported the attached images, but no longer shows the image in the imgr bbcode. Im not sure why.
At the bottom of the wiki there is a black block in an odd location. I assume this is where the image should be displayed, because it lists the 'author' and links to the image page. Yet the image does not show on the wiki article page, nor at the image page. It seems no images were imported. It seems there is a bug there. Please check my site to see the issue.

I wonder if vaultwiki is supposed to redirect vbulletin attachments to VW4 attachments. And if so then does this not conflict with xenforo its redirect script? Or is VW4 supposed to rewrite specific links in wiki articles from vb attachments to VW4 images? How does this work?

After having thought about the system some more, I think it could also work for me if the image pages would not be visible anywhere. i.e. just link directly to the image file from within the wiki and not show the page anywhere in VW. If this can be made possible then its solved.

Another place where images should not show up is in the find a wiki search function. An image is no wiki article and therefore images should not clutter up the search function. The search function is very handy. But not if its filled with images.

I can imagine the issue with image versioning. But I have never had an issue with it since starting the wiki 7 years ago. This may be because I only allow 7000 users to edit my wiki and all changes are moderated.

It is my understanding that your last attempt at importing images was back in Gamma 4: https://www.vaultwiki.org/issues/3655/
If that's the case, then you have already reported that bug and it seems to be fixed in the newer releases. If I recall, you had expressed that you would test other features for a while rather than diving into another import so soon. As a reminder, the bug was related to the database fallback not working for vBulletin 3 source attachments when guest permissions to view them normally were disabled.

For the imgr tags that I see not working, make sure you have created the imgr tag in XenForo's BB-Code Manager, and that "Supports Option Parameter" is set to "Yes" or "Optional", since it looks like you tend to use the option parameter in wiki pages.

If vBulletin attachment URLs are used directly in IMG tags, no VaultWiki is not equipped to handle this. It does no redirecting of old URLs of any kind. As far as wiki page URLs go, though, VaultWiki should still be able to parse your old URLs from VaultWiki 3, even though VaultWiki 3 did not follow censorship and had different language rules for URLs.

I believe it would be possible to tweak the attachment system so that the attachment's page is "hidden" based on a setting. There would still have to be a way for users to get there, though, in case they did eventually want to upload a new version, and because some types of attachments (not images, but ZIP files for example), might be better off having that page in between anyway. There is a description of the file, and for non-images, a voluntary download link. Having non-images automatically download when users click something somewhere might be a jarring experience. So that is something that we would have to figure out. For the image variants anyway, perhaps it would work similar to the way Redirects/Synonyms currently are handled (followed by default, but you can get to the synonym itself by modifying the URL).

Ah, yes, in VaultWiki 3 if changes were moderated, then only the original author could ever upload attachments to wiki pages anyway. This was a safety mechanism that was added since attachment changes could not also be moderated without fundamentally changing the attachment system. This would explain why you never encountered an issue, if it wasn't already explained when you said you rarely used ATTACH directly.

Yes, you may have a point there concerning the import issue.

I do think that VW4 should fully redirect all attachment links that relate to attachments uploaded to VW3 wiki articles. As you say these wiki forums will be deleted by everyone, so the links will go dead. Or at least there should be some way to detect dead attachment links so that users can restore those.

My wiki pages contain my most richest content and therefore there are a lot of inbound links as well as internal links to my wiki pages. You write that VW should redirect to the new url. Can you please elaborate? It would be a SEO disaster if this does not work.

Is it possible to disallow certain attachment types? I dont want wikis to have any attachments except an image. I want to keep documents, zipfiles, audio, video in dedicated nodes. Which is only possible if these are not attached to a wiki article. Its better to just load the associated files from such nodes. This way these can be re-used in multiple locations on the site. Not just on the wiki.

If you do plan to make VW attachments into a fully functional file archive of similar functionality as xenmediagallery then I can see the usefulness of it. Otherwise its just too basic for addon software that is part of a larger functionality range.
The same people that use VW use this on the same site: http://xenmediagallery.com/media/69-...custom-30.637/ (this page unfortunately shows only a small amount of the available functions)
Which is in sharp contrast to this very basic page: https://www.vaultwiki.org/pages/Imag...s/Warning-Icon

In the same manner you can compare the xf resource manager, photopost, IP.Downloads, IP.Gallery to VW file pages. Its not in the same league. I hope that you plan to improve this new functionality so that it will be in the same league. Then it would be interesting and it would be attractive to the end user. But at the same time thats a massive project and VW needs focus on the core and essential functionality.

I see your point regarding IMG pointing to attachment.php links. This is not something that was even considered when the import system was built. By the way, if some kind of conversion like this is implemented, it would only be for stock IMG links, since those are known to be images, and it would only affect links that are posted inside the wiki. We don't parse through any source content that exists outside the wiki, so if any such links existed, those would still be broken after the import.

On the other hand, if we tried to maintain old-style attachment links as redirects to the new ones, of course only for attachments that were originally attached to wiki pages, then this would handle both cases quite nicely. The only thing that concerns me is that XenForo does this already, so we might run into a problem where both systems are trying to analyze the same links, and XenForo may not pass it off to VaultWiki on failure (although we can certainly attempt to place VaultWiki first and have it pass the request to XenForo on failure).

When I say that VW should redirect to the new URL. For most cases it will. VaultWiki's router allows for both URL-ified and un-URL-ified inputs. And if you have not changed your directory structure, everything should still point to the same place. And if you use to new /wiki/path/to/Prefix:Article scheme, /wiki/Prefix:Article automatically redirects there. There is a consideration to make, though, when you move from vBulletin 3 to XenForo.

In vBulletin 3, VaultWiki had its own showwiki.php file. In XenForo, it all funnels through index.php. If you didn't have Simple URLs turned on in VaultWiki 3, then you would need to setup an .htaccess rule that tells the server there's no showwiki.php file, but index.php?wiki/ can handle it. And if you had Simple URLs setup in VaultWiki 3, they better be setup at both the XenForo level and the VaultWiki level, or XenForo just won't catch the request to route it to VaultWiki.

There are other considerations: VaultWiki 3 allowed translation of URL replacements for different languages, and it allowed translation of custom namespace paths. This was a nice feature, but also a design flaw, because there was no way to know what the correct language interpreter should be for such an incoming URL after it was already encoded. So VaultWiki 4 doesn't have these features anymore. And while the importer does attempt to create redirects for them, due to the unknown language interpreter problem, those redirects may or may not work.

From what I see of XenMediaGallery, there is not really anything there that cannot already be achieved with included functionality for VaultWiki attachments, with some minor exceptions. Share links / social bookmarking / whatever you want to call it is missing due to a regression and would be functionality for wiki pages across the board, including attachments. There is also a regression in the ability to rate pages, attachments, what have you, but that requires us to finish rebuilding the Polling / Ratings system which is currently being specced out.

The only thing that's currently missing, that really would not be a lot of work to add is to separate image listings from page listings and so feature them with image previews directly in the directory listings, as opposed to the way it is currently only listed by filename. This has been planned functionality for some time.

Since the bug count has come down we have actually been focusing on certain regressions for the next release.

Regarding showwiki.php: Why not create a showwiki.php file for VW4 redirection? This should catch old links and redirect to the new location.

Im not too bothered by the translation links. I have never gotten to get translations working in vw3 as my German section somehow ran into various errors. So we just added new articles in an island.

Its interesting to see you remarks on the comparison with xenmediagallery. Could you also compare VW4 attachment pages to the documents software on my live site? I use Link and Downloads Manager on vbulletin 3. Currently there is no replacement on xenforo. I am looking for a solution with a similar setup as xenmediagallery, but for document browsing and file downloads.