The clearly identified Forever-targeted project here is ForeverAuras - A WeakAura Fork, not a confirmed Forever release of the original WeakAuras addon. ForeverAuras lists version 1.2.2, released November 4, 2026, for the Forever flavor and game version 1.60.1.
Its author describes it as a replacement for WeakAuras2 in Forever, with configurable graphics for buffs, debuffs and other information. The project description still carries an under development during beta notice. A current file date does not, by itself, resolve every limitation or establish that an old aura import works.
Know which addon an aura requires
WeakAuras is the original project. ForeverAuras is a modified project with its own author, release numbers and issue reports. The fork acknowledges WeakAuras2 and additional code from M33kAuras, but shared ancestry is not a guarantee of identical behavior.
When someone recommends an aura, identify the addon it is designed to run in. A name, thumbnail or familiar-looking arrangement of icons is not enough. You need the intended framework and game branch before you can decide whether the import is relevant.
| Item you are choosing | What it tells you | What it does not establish |
|---|---|---|
| ForeverAuras 1.2.2 Forever file | The author's intended addon and client target | Every display or trigger works |
| An aura made for the original WeakAuras | Its intended framework | Automatic compatibility with the fork |
| A Retail or Classic aura screenshot | The appearance on that setup | Its behavior on Forever |
| A layout gallery image | An example arrangement | A complete import or supported spell list |
Open the fork's options
After installing the Forever-targeted package, open its options with /fa or /foreverauras. The author also provides a minimap icon.
Use this as the first check before adding an elaborate display. Confirm the addon name and version you installed, and that you can open its own interface. If you installed ForeverAuras, looking only for instructions addressed to the original WeakAuras can send you toward the wrong menu or troubleshooting advice.
The author presents Classic and Modern layout examples and a layout-selector image. These describe ways the fork can be presented; they do not establish a different WoW game flavor. A layout called Classic is not the same thing as installing a Classic Era build.
Beta interface reference (0.92.38), not a capture of the current 1.2.2 release.
Evaluate one display at a time
Begin with the smallest display that addresses the information you want. For example, decide which particular buff or debuff you need to notice rather than importing a full collection simply because it resembles a familiar UI.
Before accepting an import, check:
- Its stated framework, including whether the author names ForeverAuras.
- Its intended game branch and supported addon version.
- The spell, effect or other information it is supposed to display.
- Any extra scripts, dependencies or configuration it requires.
- The condition under which it should appear and disappear.
This is a selection process, not a claim that every import format or trigger type is supported. No specific import string is verified here. If the author has not described its Forever behavior, do not treat a successful-looking import as confirmation that the display will provide accurate information during play.
Recognize the limits of a fork
Forever restricts computational combat addons. A fork can adapt an interface and its code to the client, but its description is not proof that it restores every ability of an older addon.
Do not assume that a display can calculate a combat decision, obtain restricted information or automate communication merely because an older WeakAuras setup once did so. The exact current API and trigger limits are not established by the short ForeverAuras project description.
The useful test is narrower: does the particular display show the intended information correctly in the situations where you need it. Keep a fallback you can read without the display until that behavior is clear.
Define the display's expected behavior before importing
A useful aura has a clear condition and an understandable result. Write that relationship in plain language before choosing a display: when the intended effect is present, what should you see; when it ends, what should disappear. This is a way to evaluate an author's description, not a claim that the fork supports every condition you can imagine.
Then separate a display's appearance from the information it depends on. An icon can be positioned correctly even when its trigger is not working. A timer can look familiar without being verified for the intended effect. A group of class icons can resemble another player's setup without containing valid instructions for your game branch.
For the display you are considering, retain its name, intended effect and stated requirements. If you cannot identify what is supposed to make it appear, you cannot distinguish a correctly hidden display from a failed one. Avoid using a large import whose individual parts you cannot recognize as your first compatibility check.
Check visible results in a controlled sequence
After confirming the framework and package, examine one display at a time. Start in a situation where you can recognize the relevant information independently in the game. Keep the ordinary interface visible enough to compare the intended result.
- Establish the display's expected inactive state before the condition occurs.
- Trigger the relevant condition through ordinary play, if the display's requirements allow you to do so.
- Compare the displayed information with the game's own indication.
- Observe whether the display returns to its expected inactive state afterward.
- Repeat only the part that behaved unexpectedly, retaining any error and the exact action.
Do not infer broad support from this narrow check. A display that behaves as expected in one situation has not verified every trigger, class, target or combat condition in a larger collection. Equally, one failed display does not establish that every feature of the fork is broken.
If it works outside combat but fails where you intended to use it, retain that difference in the report. Do not interpret it as permission to change scripts or version labels to bypass a restriction. The required information or operation may need a different supported design.
Choose what to keep after the check
Keep a display when you can explain the information it supplies and recognize its expected behavior. If it duplicates something you already read easily, you can leave it out rather than adding another visual element to maintain.
When it behaves inconsistently, preserve the configuration needed to describe the problem and stop depending on it for the affected decision. You can continue with the game's readable indicators while checking the display's stated requirements or waiting for an applicable update.
When a package update changes the framework, reassess the particular display that matters to you. The release number changing does not tell you whether your import's condition has been fixed. Comparing the same expected behavior before and after the update gives you a clear result without claiming a complete compatibility test of ForeverAuras.
Make an issue report specific to the fork
If ForeverAuras opens but a display fails, retain the addon version, display name, intended condition and the first complete error message. Describe what happened when the condition occurred, rather than reporting only that WeakAuras is broken.
If the problem involves an imported display, separate the fork's behavior from the display author's requirements. The project directs issue reports to its own GitHub tracker or Discord. A precise report helps identify whether the fault belongs to the framework, the import or a game limitation.
Keep the original addon, the fork and the display distinct. That is the shortest route to choosing the correct file and avoiding unsupported promises about cross-version auras.