Issue: Wiki index does not work

I've mentioned this in another post, but I saw that several attachments have corrupt URL entries. Specifically, at least Nifoxipam-png is resolving to the index URL, but it discovers that's wrong too and spits out this message. VaultWiki will only try to resolve to one page at any URL, so unfortunately the inaccessible png is "covering" the index right now.

This is something I would need server access to resolve so I can read the damaged URLs and try to make sense of what caused this collision in the first place.

Perhaps there should be more protection against collisions for the index URL. Something we've been considering recently is a tool to bulk auto-rename collisions to get everything accessible again (and also as an option to avoid them).

Well there were a few problems here:
#1 - VaultWiki uses areaid = 0 to decide that a page is the wiki index and set the index title and path. While using areaid = 0 is usually okay when fetching from the database because of the default ORDER BY on InnoDb results, it is not okay to assume that all areaid = 0 content is the wiki index (there are legitimate cases where this is false). Instead, when processing data returned from the database, the content's typelist field should be checked for the index bit.

#2 - The VaultWiki 3 importer imported a large number of attachments with areaid = 0. It is not supposed to do this. When the target areaid is not known, content is supposed to be imported into the 'system' area.

#1 is now fixed in the next release.
#2 is occurring because of something weird that happened on your site. All the setting default values (you may recall this problem with the board URL) were installed as blank. I have never seen this happen before, but it meant that even though a 'system' area existed, its ID was not known by the importer. In this case, I will leave the resolution to #2 for https://www.vaultwiki.org/issues/4418/