How to fix a World of Warcraft addon after a patch

Turn error reporting on before you change anything, because a broken addon and a silent one look identical from the outside. /console scriptErrors 1 makes the game show Lua errors instead of swallowing them.

Step 1, see the errors

Two commands do the same thing:

/console scriptErrors 1
/run SetCVar("scriptErrors", 1)

With that on, a failing addon puts an error frame on screen naming the file and line that broke and the function that called it. The addon named in the error is where the fault surfaced, which is usually where it lives.

Leave it on while you diagnose and decide afterwards whether to keep it. Errors that appear once at login and never again are common and harmless. Errors that repeat every few seconds point at something in a frequently fired event.

Step 2, update before anything else

A patch that breaks an addon breaks it for everyone, and the author usually ships a fix within days. Check the addon's own page for a release newer than the patch before spending time on the rest of this.

Step 3, check the Interface number

An addon declares the game version it was built for in its .toc file:

## Interface: 100207

That is version 10.2.7, written as XXYYZZ, and the format is covered in How to install a World of Warcraft addon manually. When the number is behind the running client, the addon shows as out of date and will not load.

Tick "Load out of date AddOns" in the AddOn List frame at character select and try again. After a minor patch that changed nothing the addon uses, this is the whole fix. After a patch that removed or renamed an API function, loading it anyway produces the Lua error from step 1, because the code is broken and age was never the problem.

Editing the Interface number by hand does the same thing as the checkbox, with the same limits. It also gets overwritten the next time the addon updates.

Step 4, find which addon it is

With several dozen installed, the error rarely names the real culprit on its own, because one addon's failure can cascade into another that depends on it.

Bisect the list. Disable all addons and confirm the problem is gone. Enable half: if it comes back, the culprit is in that half, and if not, it is in the other. Repeat on whichever half fails. Six rounds finds one addon out of sixty-four.

Keep an addon that displays Lua errors properly enabled throughout, since the default error frame gives less context than a dedicated one.

Step 5, the folders, in increasing order of loss

Only reach for these when the steps above have failed, and copy the folder first.

SavedVariables files live inside WTF, which is why deleting it resets configuration instead of reinstalling anything. The addons themselves are in Interface\AddOns and stay where they are.

The client writes saved variables on a clean logout, so settings lost after a crash were never written to disk, and no amount of folder surgery brings them back.

When the addon is simply gone

Some addons are abandoned, and an API removal ends them. Two signs: the error names a function that no longer exists in the current client, and the author's page has had no release for several patches.

A replacement is usually maintained by someone else, and the search worth running is for the feature instead of the addon name.

Sources

• Console variables, Warcraft Wiki, for scriptErrors and the SetCVar form

• AddOn, Warcraft Wiki, for the out of date behaviour and the load checkbox

• TOC format, Warcraft Wiki, for the Interface number and the saved variable paths

• How to read a World of Warcraft combat log, for the other file the client writes for you