Everything WoW Companion Changelog

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

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.