Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →The Avada “Allowed memory size exhausted” message means one PHP request used more memory than the limit available to WordPress. The reliable fix is not to keep raising the limit blindly: record the complete fatal error, check the effective PHP and WordPress limits, raise them only when the host permits, then isolate plugin, theme, PHP-version, file, or OPcache conflicts. The file named in the error can identify the code path without proving that file is the underlying cause.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
What the Avada memory error actually means
PHP stops a request when its allocated memory reaches the configured memory_limit. WordPress then reports a fatal error similar to Fatal error: Allowed memory size of 268435456 bytes exhausted. WordPress describes this as an installation that does not have enough memory to accomplish the requested operation.
As an Amazon Associate I earn from qualifying purchases.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
In an Avada site, the failed request might be opening the Fusion Builder editor, saving Avada options, rendering a WooCommerce archive, importing content, updating a page, or serving a normal front-end URL. A white screen is often the visible result when the fatal error is not displayed.
A path such as wp-content/plugins/fusion-builder/inc/class-fusion-builder-options.php shows where PHP was executing when it ran out of memory. It does not, by itself, establish that Avada is defective. A second plugin, a theme compatibility issue, an incompatible PHP release, a damaged file, or an object-heavy operation can consume the memory first and fail while Avada is on the call stack.
That distinction determines the repair order: preserve evidence, measure the limits, make one reversible change, retest the same action, and isolate the cause if the error remains.
First response: preserve access and evidence
1. Make a current backup
Back up the database and the complete WordPress files before editing configuration, deleting cache data, changing PHP settings, or rolling back an update. A backup gives you a recovery point if a syntax error in wp-config.php or a failed update takes the site offline.
Recommended Free Tools
2. Copy the entire fatal message
Save the exact text, not just the words “memory exhausted.” Record:
- the requested allocation and the allowed limit in bytes;
- the PHP version;
- the URL or administrative action that triggered it;
- the complete file path and line number;
- whether the failure occurs on the front end, in wp-admin, or only in the Avada/Fusion Builder editor.
These details let you compare two failures accurately. A different limit, file, URL, or line can indicate that the first change altered the symptom rather than fixing the cause.
3. Use Recovery Mode if WordPress offers it
For a critical error, WordPress may send the site administrator an email with a Recovery Mode link. Follow that link to sign in while the suspected extension is paused for your session, then inspect the error and deactivate the component that prevents access. Recovery Mode is an access mechanism, not proof that the paused component is the root cause; continue with logging and controlled tests.
4. Avoid repeated blind retries
Do not repeatedly click Save, publish, or import while the request is already exhausting memory. Repeated attempts can create partial settings or imports and make the log harder to interpret. Note the exact action, make one change, and run that same action once during each test.
Check the effective memory limits before changing anything
Three settings are commonly confused. The server-level PHP limit is the ceiling WordPress must work within; the WordPress constants are requests to use part of that ceiling for different kinds of requests.
| Setting or source | What it controls | Where to inspect | Important qualification |
|---|---|---|---|
memory_limit |
PHP’s per-request server ceiling | Avada’s system/status screen, the host’s PHP information page, or a host-provided PHP diagnostic | If the host enforces a lower value, WordPress cannot raise it from its own configuration. |
WP_MEMORY_LIMIT |
WordPress’s requested memory for ordinary/front-end requests | wp-config.php and the effective value shown by the site’s status tools |
It is a WordPress request, not an override of a host-enforced PHP ceiling. |
WP_MAX_MEMORY_LIMIT |
WordPress’s requested maximum for administration tasks | wp-config.php and the effective admin status information |
Editing, imports, media processing, and other dashboard operations can need a different value from front-end requests. |
WordPress attempts 40 MB for a single-site installation and 64 MB for multisite by default. Those are WordPress configuration defaults, documented by WordPress.org in 2023 and shown on the page last updated October 14, 2026; they are not a universal Avada requirement. A site can fail below or above those figures depending on its plugins, content, PHP version, and operation.
Read the limit in the context of the failing request
An editor-only failure points toward the administration ceiling and the code loaded by the editor. A front-end-only failure may involve a template, a WooCommerce query, or a feature that is not loaded in wp-admin. Compare the effective values in both contexts rather than assuming that one displayed number applies everywhere.
Raise WordPress’s requested limit safely
Only make this change after recording the original settings and confirming that your hosting plan permits it. Use a staging copy first whenever possible.
1. Edit wp-config.php in the correct location
Open the wp-config.php file in the WordPress installation root. Add the constants before the line that loads WordPress, normally the line containing require_once ABSPATH . 'wp-settings.php';. Do not place them after that line, where WordPress may already have initialized its memory settings.
define( 'WP_MEMORY_LIMIT', '128M' );
define( 'WP_MAX_MEMORY_LIMIT', '256M' );The values above are examples of a front-end request of 128 MB and an administration maximum of 256 MB. They are not a guaranteed Avada requirement or a universal “correct” setting. Use the smallest values that allow the documented operation to complete, subject to the server’s ceiling.
Rank #3
2. Preserve valid PHP syntax
Keep the constants outside any function and use the exact quotation marks and semicolons shown. If the file already defines either constant, edit the existing definition instead of creating a duplicate. A missing semicolon or an edit in the wrong file can produce a new critical error unrelated to memory.
3. Verify that the host accepted the request
Return to the Avada system/status screen or the host’s PHP information and check the effective values. If the displayed PHP memory_limit remains lower than the requested WordPress value, the host is enforcing the ceiling. Ask the host to change the server-level memory_limit or explain which account-level setting is permitted; changing wp-config.php alone cannot bypass a provider restriction.
Why a larger number is not a complete fix
WordPress warns that increasing its memory limit can hide a memory-intensive function until a later plugin, feature, or content change causes the failure again. More memory can also reduce the capacity available to other PHP workers on a constrained server. Treat a higher limit as a controlled mitigation while you test the underlying operation, not as evidence that the conflict is resolved.
Retest the exact action and classify the result
After each change, repeat the URL or action that originally failed. Record one of four outcomes:
- It succeeds: keep the smallest tested setting that is stable, then continue monitoring and test related operations.
- The fatal error moves to another file: the request is still exceeding its ceiling; the newly named file is another participant, not automatic proof of a new root cause.
- Only one editor, import, archive, or option screen fails: focus isolation on the components loaded by that workflow.
- The same failure returns after a cache clear or later request: investigate a persistent conflict, an OPcache issue, or a server resource constraint rather than increasing the number again.
Keep a short change log with the old and new limits, the tested action, and the resulting error. It prevents circular troubleshooting and gives a host or vendor reproducible evidence.
Isolate plugins, themes, and PHP compatibility issues
Enable logging on staging or during a maintenance window
On a staging copy, or briefly while visitors are protected by a maintenance plan, enable WordPress debugging and the debug log in wp-config.php:
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstalldefine( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Reproduce the failure once, then inspect wp-content/debug.log. Keeping display disabled prevents stack traces from being exposed to visitors. Turn debugging off after the controlled test, especially on a public production site.
Deactivate plugins using a controlled sequence
- On staging, deactivate all plugins except the components required to reproduce the workflow, if the workflow allows it.
- Test the same Avada or front-end action.
- If it succeeds, reactivate plugins one at a time, testing after each activation.
- When the failure returns, leave the suspected plugin inactive and test with the remaining set to confirm the interaction.
If wp-admin is unavailable, use the host’s file manager or database-backed plugin controls only if you know how to restore the original state; make a backup first. Do not delete plugin files as a first diagnostic step.
Test with a default WordPress theme
Temporarily switch the staging site to a default WordPress theme while keeping the same plugins and content. If the error disappears, compare the Avada template, options, and compatibility with the failing feature. If it remains, the theme is less likely to be the sole trigger, although Avada may still be part of the execution path.
Consider PHP-version compatibility and damaged files
WordPress identifies incompatible PHP versions and corrupted files, along with plugin conflicts, theme compatibility, and insufficient memory, as common causes of critical errors. Compare the PHP version and extension set on staging and production. If the problem began after a PHP change, test a vendor-supported version on staging rather than changing production blindly. If files are incomplete or modified, reinstall the affected component from a verified package after preserving its settings and backup.
Apply the specific Fusion Builder OPcache workaround only when it matches
SiteGround documents a particular pattern: a fatal error naming wp-content/plugins/fusion-builder/inc/class-fusion-builder-options.php. For that case, its guidance is to delete the hidden /.opcache directory in the hosting account’s home directory.
Safe procedure
- Back up the site and copy the complete fatal message.
- Confirm that the path and symptoms match the documented Fusion Builder pattern rather than deleting arbitrary cache folders.
- Use the host’s file manager, SSH, or FTP method to locate the hidden
/.opcachedirectory in the account home directory. - Delete that directory only after confirming its location and scope. If you cannot identify the correct account-level directory, ask the host to perform or verify the operation.
- Retest the exact Avada action and inspect the log for a changed or resolved signature.
The SiteGround article was last updated August 19, 2021. Its workaround is therefore a targeted remedy for the matching hosting pattern, not permission to remove every directory named “cache” or “opcache” on every provider.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Update or roll back components without losing the evidence
On staging, bring WordPress, Avada, Avada Core/Fusion Builder, WooCommerce, and other plugins to releases that are compatible with the tested PHP version. Take a backup before each coordinated update and test the editor, the affected front-end URL, and any import or archive involved.
If the fatal error began immediately after one update, first reproduce it on staging with that component changed while the rest of the stack remains constant. Roll back the changed component on staging to confirm the relationship, then report the reproducible conflict to its vendor. Do not roll back unrelated components or update everything at once when you are trying to identify a single change.
Free tools Windows power users keep installed
One-click scans. No signup required.
Choose the remedy that fits the evidence
| Option | Scope of change | Host permission needed | Reversible? | What it proves or does not prove |
|---|---|---|---|---|
Set WP_MEMORY_LIMIT or WP_MAX_MEMORY_LIMIT |
WordPress requests more memory for selected request types | Only if the server ceiling permits it | Yes; restore the previous constants | May let a legitimate operation finish, but does not identify a loop or heavy plugin. |
Raise PHP memory_limit with the host |
The PHP runtime ceiling for the account or server | Yes | Usually; follow the host’s procedure | Confirms a ceiling constraint, not that Avada is the root cause. |
| Plugin/theme isolation | The code loaded by the failing workflow | No, but use staging or a maintenance window | Yes; reactivate components one at a time | Can reveal a reproducible conflict and its trigger. |
Delete the matching /.opcache directory |
Account-level cached PHP bytecode in the documented SiteGround case | Often host access or confirmation | Cache is regenerated; back up first | Relevant only when the fatal path and hosting pattern match. |
| Update or stage a rollback | Component compatibility and changed code | No for updates; vendor/host policy may govern rollback | Yes with a backup and tested package | Useful when the failure correlates with a specific release. |
| Escalate to host or Avada | Server controls or vendor code/support | Not applicable | Depends on the requested change | Provides specialist access when logs and isolation identify the responsible layer. |
Use the symptom to choose the next test
The whole site is a white screen
Use the administrator email’s Recovery Mode link if available. If not, use the host’s file or database controls to regain access, then inspect the complete fatal message and enable logging on staging. Do not assume that the theme or the file named in the message is solely responsible.
Only Fusion Builder or Avada options fail
Compare the administration memory value with the server ceiling, test with nonessential plugins disabled, and check whether the documented Fusion Builder options-file path appears. If it does, evaluate the targeted OPcache procedure with the host before deleting anything.
Only a WooCommerce archive or front-end template fails
Test the same URL with a default theme and nonessential plugins disabled. An editor-only memory increase will not fix a front-end request that loads a different template or query. Keep the URL, PHP version, and resulting log entry in the change record.
The error persists after raising both WordPress constants
Verify the actual PHP memory_limit; the host may have ignored the requested values. If the effective ceiling is higher and the same request still fails, stop increasing it and isolate plugins, theme compatibility, PHP version, and file integrity.
The error changes location after the increase
Interpret the new path as evidence that the request progressed farther before exhausting memory. Compare both logs and continue isolation rather than treating the second path as an automatic root cause.
Prevent a recurrence
- Keep staging close to production and test Avada, Avada Core/Fusion Builder, WooCommerce, plugins, and PHP changes there first.
- Retain backups before configuration edits, updates, rollbacks, and cache-directory changes.
- Document the effective front-end and administration limits, not just the constants requested in
wp-config.php. - Keep a dated record of PHP-version changes and the first URL or action that failed.
- Review
wp-content/debug.logafter a controlled reproduction, then disable public debugging. - Use the smallest stable memory values; a permanently oversized ceiling can hide an inefficient or looping operation and consume server capacity.
When to contact your host or Avada support
Contact the host when
- the PHP
memory_limitstays below the value WordPress requests; - PHP workers are constrained or the site fails even after a controlled isolation test;
- OPcache is managed centrally or you cannot identify the correct account home directory;
- you need the provider to verify or remove the documented account-level
/.opcachedirectory.
Send the host the complete fatal message, effective PHP limit, PHP version, URL or action, timestamp, and the changes already tested.
Contact Avada when
After plugin and theme isolation, the logs continue to implicate Avada or Fusion Builder on a reproducible workflow. Avada states that its documentation and video tutorials are supplemented by hands-on support; a registered My Avada account is required to submit a ticket. Include the staging reproduction steps, the exact component versions, PHP version, memory values, debug-log excerpt, and confirmation that unrelated plugins and a default theme were tested where practical.
Quick Recap
A concise recovery checklist
- Back up the database and files.
- Copy the complete fatal message and record the action, URL, PHP version, and limits.
- Use Recovery Mode or the host’s access tools if the dashboard is unavailable.
- Check the effective PHP,
WP_MEMORY_LIMIT, andWP_MAX_MEMORY_LIMITvalues. - Raise WordPress’s requested values only before
wp-settings.php, and only within the host’s ceiling. - Retest the exact failing action once.
- Enable logging on staging, isolate plugins, and test a default theme.
- Apply the account-level
/.opcachedeletion only for the documented matching Fusion Builder pattern. - Update or roll back one correlated component on staging.
- Escalate with the complete evidence when the server or vendor layer remains implicated.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →
