promotional bannermobile promotional banner

Azeroth Journal for Classic Era/Hardcore

Azeroth Journal is an Adventure Guide-style dungeon and raid journal for WoW Classic Era.

File Details

AzerothJournal_Classic_1.1.2.zip

  • R
  • Jun 24, 2026
  • 23.15 MB
  • 7
  • 1.15.8+8
  • Classic

File Name

AzerothJournal_Classic_1.1.2.zip

Supported Versions

  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
## [1.1.2] - 2026-06-24

### Added

- Shift+Left-click on an item (loot list, quest reward/start items, search results) now also works like AtlasLoot/Auctionator's item linking: if the Auction House search box currently has keyboard focus instead of a chat editbox, the item gets inserted there instead of into chat, via Blizzard's own `ChatEdit_InsertLink`. Quest links deliberately keep working chat-only, since a quest link isn't a usable Auction House search term
- Shift+Left-clicking several quests one after another (eg. multiple quests in the same dungeon's quest list) now accumulates all of them into the same chat message instead of needing to send each one separately - each click inserts at the cursor with a separating space rather than replacing what's already typed
- A real settings page under Esc > Options > AddOns > Azeroth Journal (the same panel system BugSack, Leatrix Maps, and other addons hook into on this client), also reachable by right-clicking the minimap button or via `/journal config`: rebind the journal's toggle shortcut (click the key box, then press a new key - defaults to Shift+J), a window scale slider (10%-250%), a window transparency slider (0%-100%), a checkbox to lock the minimap button in place, a checkbox to hide it entirely, a checkbox to mute this addon's own UI sounds, and a "Reset to Defaults" button. All of these are remembered per character

### Fixed

- Confirmed live that the item chat links above (and the same hand-built links carried over from earlier versions) silently failed to send in chat at all - the message just never appeared, for the sender or anyone else - while AtlasLoot's own item linking worked fine right next to it. The difference: this addon was hand-building the `item:` hyperlink string field-by-field rather than using a real link from the client. Items now use `GetItemInfo`'s own real link whenever it's cached (which it normally is, since this addon already primes item tooltips), falling back to the previous hand-built string only if it somehow isn't
- Quest links had the exact same "silently never sends" symptom, but it turned out to be unrelated to formatting - confirmed live that even a real `GetQuestLink()` string, for a quest sitting in the player's own quest log, still failed to send. Questie (Classic's most-used quest addon) hits the same wall and has never tried sending a real quest hyperlink for this reason - every one of its own chat-link features inserts plain `"[[level] name (id)]"` text instead, with no color codes at all. Quest links here now use that exact same shape (confirmed live that adding a color wrapper around it was still enough to make it vanish on send again, so it's left bare): it survives sending, and as a bonus, Questie's own incoming-chat filter recognizes that exact pattern and quietly turns it into a real clickable quest link with a live status tooltip for anyone who has Questie installed - independently of whether they have this addon at all
- Quest links also went on doing nothing at all (not even inserting plain text) whenever `ChatFrameEditBox:IsVisible()` happened to read false at click time - confirmed live this could happen even with chat visibly open. It then turned out `:IsVisible()` was *also* unreliable on the second shift-click of a session specifically, re-opening a fresh chat line and wiping out the first quest instead of appending the second. Both replaced with `ChatEdit_GetActiveWindow()` - the actual check `ChatEdit_InsertLink` itself uses for this, which doesn't share either failure mode - falling back to `ChatFrame_OpenChat` only when there's genuinely no active chat window at all
- Capturing a new shortcut key immediately popped the journal window open the instant it was bound, since keyboard propagation was being re-enabled synchronously inside the very same key-down event that had just set the binding - letting that same press fall straight through to the freshly-bound action. Deferred re-enabling propagation by one frame so the press that sets the shortcut never also triggers it