Change Details

Clients have no good way to know the internal ID associated with a wiki, but they usually know the wiki's domain name. API modules that expect an internal wiki id, such as wbsetsitelink, should accept the domain as an alternative to the internal wiki ID. When resolving the ID, we could either fall back to lookup by domain if lookup by global ID fails, or we could choose the lookup strategy by identifier sytanx: domain names always contain a ".", internal IDs never do.

Clients have no good way to know the internal ID associated with a wiki, but they usually know the wiki's domain name. API modules that expect an internal wiki id, such as wbsetsitelink, should accept the domain as an alternative to the internal wiki ID. This should also work for addressing items by wiki+title, where we currently require the wiki id. When resolving the ID, we could either fall back to lookup by domain if lookup by global ID fails, or we could choose the lookup strategy by identifier sytanx: domain names always contain a ".", internal IDs never do.

Clients have no good way to know the internal ID associated with a wiki, but they usually know the wiki's domain name. API modules that expect an internal wiki id, such as wbsetsitelink, should accept the domain as an alternative to the internal wiki ID. This should also work for addressing items by wiki+title, where we currently require the wiki id. When resolving the ID, we could either fall back to lookup by domain if lookup by global ID fails, or we could choose the lookup strategy by identifier sytanx: domain names always contain a ".", internal IDs never do.