Wiki Links with Aliases not working

Let me start by saying 1.9 is awesome and completely worth the wait! Alas, I think I’ve stumbled across a bug with the Wiki Link functionality and how it interacts wth aliases.

In summary, Wiki links will automatically be created for all aliases, but only links to the first alias listed in the Info Palette for a given document will actually point to that document. Any automatic Wiki-links to additional aliases for a document will not point to that document but will instead create a new document with that alias’ name when the link is clicked.

This happens:
–whether commas or semi-colons are used to separate multiple aliases
–in both 1.9 and 1.9a
–in an existing (pre-1.9) database
–in a brand new empty database
–whether files are in a group or at the main level of the database

Here are detailed step-by-step procedures to reproduce:

  1. In Preferences --> Editing, make sure Wiki Links Automatic is checked, as are “Names and Aliases” and “Don’t link to Groups”
  2. Create a group called “Characters”
  3. Create a new Rich Text item in the “Characters” group, call it “Alex Johnson”
  4. Give the new note the following aliases in the Info palette: “Alex, Alexander, Alexander the Great”
  5. Create a new Rich Text item in the “Characters” group, call it “Jane Doe”
  6. In the “Jane Doe” rich text note, enter some text, and be sure to make specific reference to the name of the first note we created as well as each of the 3 aliases (e.g., “Jane is in love with Alex Johnson because Alex goes by Alexander and is also known as Alexander the Great”)

You’ll find the following:

–An automatic and functional link will be created for the reference to “Alex Johnson” (you might have to select another note and then re-select the note for Jane Doe to get the links to appear)

–A link will be automatically built for the aliases “Alex”, “Alexander”, and “Alexander the Great”, but instead of pointing to and opening the rich text note for “Alex Johnson”, clicking these auto-wiki links will instead create a new rich text note with the respective name, e.g., clicking “Alex” will create a new rich text called “Alex” in the “Characters” group instead of linking to the existing rich text “Alex Johnson” (with “Alex” as one of its aliases)

–Repeat the above, but for the other aliases in our example, “Alexander” and “Alexander the Great”; same effect.

Can anyone else try this out and confirm if the behavior is the same on your system using DEVONthink PE 1.9?

I’ve verified and repaired the database (no problems), and rebuilt the database. No change in the behavior. Any ideas? Should I try trashing the preferences? Or is this a bug?

There’s an undocumented restriction which might cause this problem - aliases have to be separated by commas or semicolons without spaces and therefore…

Alex, Alexander, Alexander the Great

…should be…

Alex,Alexander,Alexander the Great

However, v1.9.1 will fix/improve this.

Hmmm… this doesn’t fix the other issue (creating new notes instead of jumping to the existing one). Will check this.

Thank you for the response! The primary issue is indeed that any alias entries beyond the first create new notes instead of going to the existing ones.

Interestingly, I just tried listing multiple aliases with 1.9a, and all references to them are recognized and automatically made into Wiki links, whether or not I have spaces after the comma or semi-colon. E.g., both formats of “Alex,Alexander,Alexander the Great” and “Alex, Alexander, Alexander the Great” seem to be recognized and references to them are made into links. The trouble is that any references beyond the first alias don’t point to existing files but instead create new ones.

Thanks for the quick response and for investigating!

Depending on the text you’re writing, aliases with one or more surrounding spaces might or might not work. However, v1.9.1 will always ignore the spaces.


Thanks for making a great program. It would be great if the Wiki links could work as advertised (i.e. if the aliases would point to the right document instead of creating a new one). Do you know when 1.9.1 will be ready?


The latest build treats the aliases right and therefore v1.9.1 will be probably available next week.