This wiki contains inaccurate and out-of-date information. Please head over to for more accurate and up-to-date game information.



This article covers the cumulative AddOn UI Customization and Macro API changes after WoW 4.0.1 through 5.0.5 for Mists of Pandaria (Mists/MoP). See API change summaries for a list of API change summaries for all patches.
API change summaries

Breaking Changes


Important Notes

  • As of 9/27/2012 the Blizzard WoW AddOn Kit is out of date. It is not representative of 5.0.4 or newer UI art and code.

Blue Posts

Party and Group APIs

Several of the specialized Party and Raid functions and events have been consolidated. The naming convention cleanup is basically that: 'Party' and 'Raid' groups have semantically become just a 'Group'; and 'Party' within a 'Raid' has semantically become just a 'SubGroup'. This effectively means that a Group is now a 'Group', whether raid or party. And a raids' parties are now 'SubGroups'. There were some return value type changes where the new GetNum functions return Lua 'true' and 'false' instead of '1' and 'nil', as is the growing trend with new fuctions after WoW went to Lua 5.0.

Similarly, the party and raid leaders have converged, while 'UnitIs..' covers 'Is..' now.

Per removal of NumParty and NumRaid, both IsInGroup() and IsInRaid() were added. 'Group', as above, means any kind of group.

  • raid status - 'GetNumRaidMembers() ~= 0' becomes IsInRaid()
  • party status - 'GetNumRaidMembers() == 0 and GetNumPartyMembers() ~= 0' becomes 'not IsInRaid() and GetNumGroupMembers() ~= 0'
  • group status - 'GetNumRaidMembers() ~= 0 or GetNumPartyMembers() ~= 0' becomes 'IsInGroup()'
  • party status - 'GetNumRaidMembers() == 0 and GetNumPartyMembers() ~= 0' also becomes 'not IsInRaid() and IsInGroup()'

And the coresponding events have merged.

Instance and Zone API

With all the changes to the back-end for greater cross-realm functionality, instance and zone semantics have changed more on the client, causing API updates or further clarification of those to fit the new world and server constructs. This is a partial grand summary of the current state.

  • instance - GetInstanceInfo() adds return value 'mapID', for transparency and disambiguation. each instanceable area has an id, incl contenents
  • instance - GetRealZoneText() will behave irratically. like at the start of a BG will sometimes report a zone/subzone rather than map name.
  • home - GetInstanceInfo() will solidly report the contenent now, which wasnt 100% the case before.
  • units - GetRaidRosterInfo() and UnitName() on zone change can provide invalid names for many minutes, for cross-realm players
  • tooltip - char info changed to support Pandarians by adding faction at the bottom, but above PvP if flagged. this affects tooltip zone lookup.

The 'instance' concept on the client is even more aligned now with the natural world load chunks, like when you have to see a loading screen. The basic containership for areas, from the servers persective, is instance/map (whether its a "persistant" one or not) -> zone -> sub-zone. Your base-line given tools are (theorectically):   tooltip method works only if in zone, in a group, or on a list

Basically using the base API, thats it... unless a player is on your friends/bnet/guild/etc... list, or by using 'who' API. The API for the Lua side has changed real meanings for these several times, towards what zone means. Normally in a regular 'home' zone, you cant target or get updates for those outside your zone or a certain radius, so theres no normal mechanism as its irrelivant to the regular WoW UI needs. Furthermore this holds true across instances as well, as it would (whether you think of instance in terms of 'specific map' or 'running copy'.) Only if you have some other association does the client get updates or potentially have the data, without specific other request. However, like the friends list, updates occur for those in a raid, party, and presumably 'senarios', together. In this case the client intends to be able to recieve and cache info for that extended set of players, besides those in your zone. Other than GetRaidRosterInfo there is no other API for accessing these, but there are workarounds.

Specialization and Talent APIs

Several of the player Talent and Specialization functions have been renamed for clarity and to be more general, and more follow the naming for Party and Groups functions.

Achievement APIs

There was some specialized Achievement API rework where function has been split, getting info by 'index' or 'id' seperately and less awkwardly. The parameter differneces are via 'criteriaIndex' and 'criteriaID' respectively.

XML Lua Object References

In addition to the existing 'parentKey' there are now a few more standard reference and related attributes. These 'key' references are used to automatically set an object reference at runtime to a its LayoutFrame object instance, which would be directly avaible to the inline script functions and other functionality. Two of the new additions, realtiveKey and targetKey, allow setting targets based on object references directly from XML.

On LayoutFrame:

On Animation:

  • parentKey (existing)
  • target - directly set the animation target by name
  • targetKey - use a 'reference' to find the target rather than a global name

On Anchor:

  • relativeTo (existing)
  • relativeKey - alternative to 'relativeTo' that uses a 'reference' instead of a global name

Key Notation

General notation for 'Keys' (object refrences) follows similar convention as the relative naming convention for 'names' in LayoutFrames, like '$parentMyChildName'. One difference is that each key reference for 'parentKey' implicitly refers to the parent already. For example

<Frame><Frames><Frame parentKey="Child"/></Frames></Frame>

where the child frame will place a reference, named 'Child', to itself on the outer frame. However, an inner frame using 'relativeKey' for an anchor must use '$parent.Child' to refer to the same key on the outer parent, as otherwise it could be refering to a key placed on itself. For example

  <Frame parentKey="Child"/>
  <Frame><Anchors><Anchor point="TOP" relativeKey="$parent.Child" relativePoint="BOTTOM"/><Anchors></Frame>

where the second inner frame will be positioned the bottom of the first inner frame.


  • The original UIPanelButtonTemplate is gone, and is now replaced by a renamed UIPanelButtonTemplate2, that existed previously. This causes all buttons (that use UIPanelButtonTemplate) to use the new scheme for rendering by tiling rather than stretching, using layer textures rather than the 'NormalTexture' and friends. This could be a visually or funcitonally breaking change for some. The stretchy buttons were argualbly simpler, but had pretty bad stretching artifacts.

Item Links

from |cXXXXXXXX|Hitem:[6 positive integers][4 negative or positive integers]|h[item name]|h|r
to |cXXXXXXXX|Hitem:[6 positive integers][5 negative or positive integers]|h[item name]|h|r


  • Inline X and Y values for XML Anchors have been officially changed from 'int' to 'float'. There were already anchors in the game resource files with float values prior to 5.0.4.