Everything WoW Companion Changelog

Each entry names the version its tag carries. The same text stands under Changes in the README.

0.2.6 records each class's talent trees for the site's talent calculators. On 20 October 2026 the owner decided the Classic three tree calculator's data is recorded by the Companion from the game client's own talent functions: Forever first, on its launch day, 4 November 2026, with a fresh character of each of the nine classes, and Classic Era later. Blizzard's Classic Game Data API publishes no talent document, and a datamined table or another site's database is not a source the site uses, so the client is the only source.

It also makes the addon silent at login and reads Forever's auction house. On 24 October 2026 the owner asked that the chat line 0.2.2 printed in Forever, "Auction recording is off for this client; the auction listener stays idle.", go away, and that the addon upload as much data as it can.

• Silent idle recorders. No recorder prints anything at login any more. The idle auction line 0.2.2 added was the only one; it is gone, and /ewow status now names the recorders that cannot run on the client instead, on an idle on this client: line, for example "kill counter (combatLog off)" on Forever or "auction recording (the site reads Blizzard's auction API)" on Retail. Every command's own output, /ewow status, /ewow probe, /ewow talents and the rest, is unchanged, and so is the line a forbidden action report prints.

• Forever's auction house, read from your own searches. Forever's client carries the Retail project id, so its auction house is the modern C_AuctionHouse one, which the classic AUCTION_ITEM_LIST_UPDATE scan cannot read, and Blizzard publishes no auction API for Forever's realms. A new reader in Auction.lua reads what your own searches have already loaded: the browse list (AUCTION_HOUSE_BROWSE_RESULTS_UPDATED and _ADDED, through C_AuctionHouse.GetBrowseResults: each row's item, lowest price and total quantity), a commodity search (COMMODITY_SEARCH_RESULTS_UPDATED and _ADDED: each listing's unit price and quantity) and an item search (ITEM_SEARCH_RESULTS_UPDATED and _ADDED: each auction's buyout and quantity). It never sends a query of its own, never reads a seller, an owner list or a bidder, and writes the classic scan's own shape, { items = { { id, q, unit, buyout } } } in copper, 50 rows to an observation and at most 500 rows for one announcement, with a source field naming which of the three reads wrote it, since a browse row's price is the lowest of every listing of the item. A search repeated within a minute reads only the rows the client added.

• A new capability, auctionModern. On for Forever and every classic row, off for Retail, whose auctions the site reads from Blizzard's own API, and for an unknown client. The reader registers its events only the first time you open the auction house out of combat, never at login, and only the ones the client says exist (C_EventUtils.IsEventValid) and whose getters it carries, so a client without C_AuctionHouse registers nothing at all. Every call sits inside pcall, nothing runs in combat, and a refusal of any of its events turns off auctionModern alone. The same reader serves Cataclysm Classic and Mists Classic wherever they carry C_AuctionHouse, and the classic scan now steps aside only where the browse list can actually be read. /ewow probe asks about the reader's seven events too, nineteen in all.

• /ewow talents. Reads the current character's class trees and keeps them: the class file token, the site's class slug and the class id, the client key, WOW_PROJECT_ID, the build, build number and interface number from GetBuildInfo, the character's level, a timestamp and the addon version, then every tree (id where the client gives one, index, name, icon, background) and every talent (id where the client gives one, name, icon, tier, column, maximum rank, the milestone mark, and each prerequisite by tier and column with the prerequisite's id and index where it resolves). It prints, for example, "Recorded 3 trees, 51 talents for Warrior. /reload or log out to save." and the classes held so far for the client. Nothing about the character beyond its class and level is written: no name, no realm, and no rank the character has spent.

• Both talent APIs, behind feature detection. Forever's client carries the Retail project id, so its talents may come through the classic functions (GetNumTalentTabs, GetTalentTabInfo, GetNumTalents, GetTalentInfo, GetTalentPrereqs, and GetTalentLink for the id) or through the modern ones (C_ClassTalents.GetActiveConfigID and C_Traits' config, tree, node, entry and definition info). Both are read, every call inside pcall, the classic shape first. A trait node's tier and column are its rank among its tree's heights and widths, with the raw position kept beside them, and its prerequisites are the nodes whose arrows point at it. Where both answer, the second is kept beside the first under alt. Where neither answers, the capture is a diagnostic naming which of the functions the client has and why each path gave nothing, and a level one character is told to try again at level 10. A failed read never replaces a good capture of the same class. The command waits for the player to leave combat.

• Its own saved variable. The captures live in EverythingWoWTalentsDB, declared beside EverythingWoWDB in both tables of contents and written into the same EverythingWoW.lua, one per class per client under a <client>:<CLASS> key, so a second read of a class replaces the first and nine classes give nine entries. The site's upload page reads EverythingWoWDB alone and sends only its version, patch, addon and observations, so the captures never reach the upload's validation, its observation count or its payload caps, and an upload of the file goes through exactly as before. The site does not read the captures yet, so on launch day the file goes to the Orchestrator. /ewow clear leaves the captures alone, and /ewow talents clear throws them away.

• The version, the path line and the tests. Both tables of contents carry ## Version: 0.2.6 and keep the ## Interface lists 0.2.5 wrote, 120100, 50504, 20506, 16001, 11509 and 11509. /ewow path now prints the game folder, _<flavor>_, in the path. The test stand in's GetBuildInfo reads unpack where table.unpack is missing, so the suite runs under Lua 5.1, the game's own Lua, as well as 5.4. The tests read a three tree classic shape with an arrow, a C_Traits shape with an edge, a choice node and an empty node, both at once, and neither, and the Retail and Forever files they write carry EverythingWoWTalentsDB beside EverythingWoWDB, the Forever one with all nine classes, so the worker's file check proves the site's parser still accepts a file holding both. The tests also drive the modern auction reader through a stand in C_AuctionHouse on Forever, Retail, Cataclysm Classic and Classic Era, and the Forever file now carries a browse page and a commodity search; the suite reads 548 assertions, from 459, under Lua 5.1 and 5.4.

0.2.5 keys a Wrath of the Lich King Classic or Cataclysm Classic session as the site's own rows without declaring either client to the stores. On 28 September 2026 the site's versions table gained two rows, classic_wrath and classic_cata, both left disabled, and the site's upload path reads every row whether or not it is enabled, so an upload keyed to either is accepted while no page of the site shows either dataset.

• Wrath of the Lich King Classic and Cataclysm Classic read as themselves. Once the Forever and Retail checks have passed, EW.ReadClient now keys a session of version major 3 as classic_wrath and one of major 4 as classic_cata, beside majors 2 and 5, and a readable major of 6 or above off the mainline project id still reads unknown. EW.VersionKey answers with the client key outright for both, as it does for forever, classic_tbc, and classic_mop, so db.version and db.client agree for both. /ewow status prints the new keys through the same game and client lines it has printed since 0.2.1. Under 0.2.4 a 3.x or 4.x session was keyed unknown, a key the site refuses, so its upload was turned away.
• Two new capability profiles. classic_wrath and classic_cata carry Classic Era's row: worldCursor off, and unitGuid, combatLog, and auction on. Auction.lua's own scan steps aside wherever C_AuctionHouse exists, so the row holds whichever auction window each client carries. No other Lua file reads the client key, so none of them changed.
• No new client declared. Both tables of contents carry ## Version: 0.2.5 and keep the ## Interface lists 0.2.4 wrote, 120100, 50504, 20506, 16001, 11509 and 11509, so the stores offer this release for the same five clients. Neither Wrath of the Lich King Classic nor Cataclysm Classic can be played in a region the site reads, us, eu, kr, or tw: the only 3.x client still running is Titan Reforged, a China only Classic+ client at 3.80.2, and Cataclysm Classic's realms moved to the Mists of Pandaria pre-patch on 1 July 2025. Declaring either client would offer a download no player in those regions can use.

0.2.4 declares every client the site holds and keys their uploads correctly. The site's versions table held exactly five enabled rows when read on 27 September 2026, retail, classic_era, classic_tbc, classic_mop, and forever, but 0.2.3's tables of contents carried only the Retail and Classic Era interface numbers, so the stores offered that release for those two clients alone. The README's Wago link also moves to the project's renamed address, https://addons.wago.io/addons/everything-wow-companion, the id kGr9yAKy being unchanged.

• Burning Crusade Classic and Mists Classic read as themselves. Once the Forever and Retail checks have passed, EW.ReadClient now keys a session by its version string's major: 2 reads classic_tbc (Burning Crusade Classic Anniversary, 2.5.x), 5 reads classic_mop (Mists of Pandaria Classic, 5.5.x), 1 below Forever's minimum reads classic_era or hardcore as before, and any other readable major off the mainline project id, such as Wrath of the Lich King or Cataclysm Classic, reads unknown and takes the most restrictive capability row. Under 0.2.3 a Burning Crusade or Mists session fell through to the Classic Era branch, was keyed classic_era, and wrote classic_era into db.version, so its upload would have landed in the Classic Era database under the wrong key.
• The upload's key follows the client's. EW.VersionKey answers with the client key outright for forever, classic_tbc, classic_mop, and unknown, so db.version and db.client cannot disagree for any of the four, and otherwise answers as it always has: retail for the mainline project id, and hardcore or classic_era for the rest. An unknown key is one the site's upload page refuses, since its versions table holds no such row, where 0.2.3 sent classic_era for the same session. /ewow status prints the new keys through the same game and client lines it has printed since 0.2.1.
• Two new capability profiles. classic_tbc and classic_mop carry Classic Era's row: worldCursor off, and unitGuid, combatLog, and auction on. Neither client has C_TooltipInfo.GetWorldCursor, and both keep the combat log. Auction.lua's own scan runs only where C_AuctionHouse is absent and steps aside where it exists, as it does on Retail, so the row holds whichever auction window each client carries. No other Lua file reads the client key, so none of them changed.
• Five clients declared. EverythingWoW.toc now carries ## Interface: 120100, 50504, 20506, 16001, 11509, for Retail 12.1.0, Mists Classic 5.5.4, Burning Crusade Anniversary 2.5.6, Forever 1.60.1, and Classic Era 1.15.9, and the packager reads that list as five game versions. EverythingWoW_Vanilla.toc keeps ## Interface: 11509. Wrath of the Lich King and Cataclysm are not declared, because the site holds no version rows for them and would refuse their uploads.

0.2.3 sends the forever version key for a Forever session. The site's versions table has had its forever row enabled since 24 September 2026, so the asymmetry 0.2.1 documented is closed.

• Forever recordings land under Forever. EW.VersionKey, the key written to db.version, now answers forever whenever EW.Client reads as forever, that is, a version string of major 1 and minor 60 or above, whatever project id the client carries. The upload's own field therefore reads forever for the owner's build 1.60.1 session, and its recordings land in the Forever database rather than Retail's. Retail, Classic Era, Hardcore, and a client the table cannot place answer exactly as they did in 0.2.2.
• db.client still rides beside it. It carries the client this addon detected, now the same key as db.version for a Forever session, and /ewow status's game line still reads it. Nothing else changed: the capability table, the probe, the forbidden handler, and every recorder are exactly as 0.2.2 shipped them.

0.2.2 settles the Forever capability profile on the owner's own /ewow probe transcript, run against 0.2.1 on build 1.60.1: NAME_PLATE_UNIT_ADDED, UPDATE_MOUSEOVER_UNIT, and PLAYER_TARGET_CHANGED came back allowed, COMBAT_LOG_EVENT_UNFILTERED and AUCTION_ITEM_LIST_UPDATE came back refused, and the owner's own /ewow cap worldCursor on and /ewow cap unitGuid on afterward raised no alert. The same transcript also showed a second alert the probe itself caused: ADDON_ACTION_FORBIDDEN reported for EverythingWoWFrame:UnregisterEvent(), which turned every restricted capability off, worldCursor and unitGuid included, on the strength of a refusal 0.2.1 could not place.

• The Forever profile. worldCursor and unitGuid now default on for Forever, combatLog stays off, and a new auction capability, gating AUCTION_ITEM_LIST_UPDATE and this addon's own auction API calls, defaults off too. Retail's auction capability is on, and Classic Era and Hardcore keep their long standing unrestricted behavior, where Auction.lua's own scan is the only way the auction house gets recorded at all.
• A refused registration is never followed by an unregister call. The probe used to call UnregisterEvent unconditionally after every attempt, including a refused one, but a refused registration was never actually registered, so there was nothing to unregister, and the owner's own build 1.60.1 session proved that calling it anyway is itself forbidden. The probe now skips that call entirely when the registration was refused.
• An UnregisterEvent refusal is attributed to the exact event, the same as a RegisterEvent refusal. Two bugs combined to make 0.2.1's fallback the wrong one: EW.lastRegisterAttempt was already cleared by the time the unconditional unregister call ran, and NamesRegisterEvent's substring check for "RegisterEvent" does not match "UnregisterEvent", which spells its own register with a lowercase r. EW.UnregisterEvent, a new counterpart to EW.RegisterEvent, sets EW.lastRegisterAttempt around the client call, and NamesRegisterEvent now checks for both spellings, so a refusal there turns off only the one capability that event feeds.
• The probe's tally counts every event exactly once, allowed or refused, whether or not its own cleanup call is refused too.
• Loot with combatLog off. On a client without the combat log, such as Forever, this recorder's kill counter never runs, so a kill that drops nothing is never recorded there; a kill that drops something is unaffected, because it is read off the loot window's own source guid rather than off anything the combat log tracked. Separately, a loot window whose source guid cannot be placed at all, on any client, no longer loses its items: the observation is still recorded, with its subject and its payload's source_type marked "unknown" rather than the items being thrown away.
• The idle auction recorder says so. Where auction is off, Auction.lua registers no listener and instead announces once, at the next PLAYER_ENTERING_WORLD, that auction recording is off for the client rather than staying silently idle.

0.2.1 answers what running 0.2.0 in World of Warcraft: Forever actually showed, pasted back by the owner as /ewow status: game retail and client retail (interface 16001, build 1.60.1), with last forbidden action: ADDON_ACTION_FORBIDDEN for EverythingWoWFrame:RegisterEvent() on build 1.60.1 (client retail) and every one of the three capabilities off.

• Forever detected off the version string first, whatever the project id. That paste proved 0.2.0's own assumption wrong: Forever's WOW_PROJECT_ID is the mainline id, the same one Retail reports, not the Classic id 0.2.0 expected it to share. 0.2.0 checked the project id before the version string, so a build 1.60.1 session carrying the mainline id read as Retail and switched every capability back on, which is what actually let RegisterEvent() reach the client and get refused. 0.2.1 checks the version string, major 1 and minor 60 or higher, before WOW_PROJECT_ID is even asked, so this exact session now reads as forever and every capability starts off. An unreadable version string still reads as unknown, the same restrictive row. /ewow status now prints game <client key> on its first line rather than the upload's own version key, so a person reads the client this addon actually found rather than the separate key described below.
• A RegisterEvent refusal is attributed to the event, not to nothing. The reported function, EverythingWoWFrame:RegisterEvent(), is the frame method every recorder's registration goes through, so it was never one of the specific calls FUNCTION_CAPABILITY could place, and 0.2.0's handler read that as a report it could not place at all and turned every capability off. EW.RegisterEvent now records the event it is mid call on, and a refusal naming RegisterEvent is looked up against which capability that event feeds instead, so only that capability turns off. An event that feeds no gated capability, or a report this still cannot place, keeps 0.2.0's fallback: every capability off for the session.
• /ewow probe. Attempts every event a recorder in this addon registers, one at a time through the same attribution path, undoing each attempt immediately, and prints one line per event: allowed or refused. The result is also written to the saved file under db.probe, so an upload carries it once it exists, since the payload schema already tolerates a field it does not read. This replaces waiting for gameplay to trip each restricted call in turn.
• /ewow cap <name> on|off. Flips one capability for the session, so once the probe has said which events the client allows, the tooltip hook or the GUID path can be turned on and tested on its own without waiting for a code change.
• The upload's version key is unchanged, and that is now a documented asymmetry rather than an assumed one. The site's versions table has no enabled row for forever yet, so EW.VersionKey, the key written to db.version, still has no forever branch and still sends whatever it sent before: retail for a session carrying the mainline project id, which is what the owner's own Forever session actually carries. db.client, a new field beside db.version, carries this addon's own corrected client key instead, forever for that same session, and rides along because readCompanionFile in the site's read.ts reads specific keys off the saved table and ignores any others rather than rejecting them. /ewow status reads db.client for its game line for the same reason.

0.2.0 answers the World of Warcraft: Forever compatibility block reported on 18 September 2026: an alert reading "EverythingWoW has been blocked from an action only available to the Blizzard UI. You can disable this addon and reload the UI," on build 1.60.1, naming no function.

• A capability table per client. The addon now reads EW.Client from WOW_PROJECT_ID, the interface number, and the version string as soon as Core.lua loads, rather than assuming every call works until it errors. Forever cannot be told apart from Classic Era by project id alone, since it is expected to answer with the same one, so the client key is read off the version string's major and minor instead: 1.14 and 1.15 read as Classic Era, 1.60 and up read as Forever. A client the table cannot place reads as Forever too, the most restrictive row rather than the most permissive one.
• Three capabilities gated, not merely wrapped. The world cursor tooltip hook (C_TooltipInfo.GetWorldCursor, installed inside Blizzard's own tooltip handler), the GUID reader that identifies an NPC or an object, and the combat log listener each sit behind a named capability, and every one of the three defaults off on Forever until an owner's paste proves it safe. Where a capability is off, the restricted call is never made at all: the tooltip hook is never installed, the combat log listener is never registered, and the GUID reader returns nothing rather than pattern matching or comparing what a secret value system may not allow either. The existing pcall guards stay in place, because they still catch a changed signature; they were never going to catch this alert, and they still are not what stops it.
• Forbidden action reporting. ADDON_ACTION_FORBIDDEN and ADDON_ACTION_BLOCKED are now handled when either names this addon: the reported function (or, as on the owner's own Forever alert, the absence of one), the client, and a timestamp are written into the saved file, and the matching capability, or every capability where no function is named, is turned off for the rest of the session. /ewow status now prints the client, the capability table, and the last forbidden action recorded.
• No table of contents change yet. Both ## Interface numbers are unchanged, and no third table of contents file is added. The suffix a Forever client reads is still unproven, and a guessed interface number is exactly the kind of guess this release is against.

0.1.1 fixes what the first live test on a Retail client showed.

• Vendor prices. Retail no longer has the GetMerchantItemInfo global; the merchant frame answers through C_MerchantFrame.GetItemInfo instead. 0.1.0 read only the global, so on Retail every vendor item was written with its id and no price at all. Both shapes are read now, and an item bought with a currency records that currency's id and amount beside a copper price of zero rather than looking free.
• One snapshot a session. 0.1.0 took its login snapshot on a fixed ten second timer, before the client had loaded the currency list, and could take a second one minutes later for no gain. The login snapshot now waits until the client answers with gear and currencies, and after that a snapshot is written only on /ewow snapshot, or after an hour when the gear or the level has changed.
• Honest counters. 0.1.0 counted everything it did not write as skipped, which reported 802 losses in a few minutes when almost nothing had been lost. /ewow status now separates skipped (a subject the addon could not place, the only real loss) from deduped (a sighting the five minute window already holds) and ignored (another player, a pet, a vehicle, a tooltip that is not a world object), and prints each one by reason.

0.1.0 was the first release.