News September 20, 2012 5 min read

WordPress Memory Limit: How to Fix “Allowed Memory Size Exhausted” on a Ticketing Site

A memory error on a content blog is annoying. On a ticketing site it costs real money and real trust - confirmation emails that never arrive, PDF tickets that fail to generate, checkouts that time out. Here is the practical guide to understanding WordPress memory limits, diagnosing errors, and fixing them the right way.

Few WordPress errors are as deceptively small as a memory problem. You don’t usually see a dramatic crash. What you see is a confirmation email that never arrived, a PDF ticket that failed to generate, an admin screen that goes white, or an import that dies halfway through. By the time you figure out that PHP hit its memory ceiling, a paying customer has already emailed you wondering where their ticket is.

Running an event ticketing site amplifies the problem. Checkouts, payment gateway callbacks, PDF generation, email sending, and QR code creation all run through PHP, and each one takes a bite out of your memory budget. When the site is idle you have plenty of room. When 200 people hit checkout in the same five minutes, you don’t. Here is the practical guide to understanding WordPress memory limits, diagnosing memory errors, and fixing them the right way.

What “WordPress memory” actually means

“WordPress memory” is really PHP memory. Every time a page loads, WordPress asks PHP for a block of memory to do its work in: loading plugins, running queries, rendering templates, processing forms. PHP has a setting called memory_limit that caps how much any single request is allowed to use. Hit the cap and PHP kills the request with a fatal error.

WordPress itself layers its own limits on top, one for the front-end (WP_MEMORY_LIMIT, default 40M) and one for the admin area (WP_MAX_MEMORY_LIMIT, default 256M). WordPress will not set PHP’s memory higher than PHP’s own ceiling, so both layers have to be in sync.

Signs you have a memory problem

Classic symptoms of PHP running out of memory include:

  • The White Screen of Death on specific admin pages, usually Updates, Media Library, or plugin settings that do heavy work.
  • Fatal error messages mentioning Allowed memory size of X bytes exhausted in your browser, your debug.log, or your server error logs.
  • Silent failures on tasks like email sending, PDF generation, CSV exports, and large imports.
  • Timeouts during checkout, especially when the cart triggers plugins that fetch remote data (shipping rates, tax calculations, payment gateways).
  • Ticket confirmation emails that never arrive, even though the order shows as complete. This one is common on WordPress ticketing sites and is almost always a memory or mail-queue issue.

How to check your current memory limit

Before changing anything, find out what you have. In the WordPress admin, go to Tools > Site Health > Info > Server. You’ll see both the PHP memory limit and the WordPress memory limit. If you prefer the command line, SSH in and run php -i | grep memory_limit to see the global PHP value.

As a general rule: aim for at least 256M on a live site. If you run a busy ticketing shop with PDF generation, recurring emails, or a large plugin stack, 512M is more comfortable. Anything below 128M is a 2012-era default and will bite you eventually.

Fix 1: Raise the limit in wp-config.php

This is the cleanest, most portable fix. Edit wp-config.php in the root of your WordPress install and add these lines above the line that says /* That's all, stop editing! */:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

The first line sets the front-end limit. The second sets the admin-area limit, which is where bulk operations like plugin updates and media uploads run. Save, reload your site, and re-check Site Health to confirm the new values are active.

If the values in Site Health haven’t changed, your host is capping PHP below WordPress’s request. Move on to the next fix.

Fix 2: Raise the PHP limit with php.ini or .user.ini

If your host lets you edit a php.ini or .user.ini file, add or change the line:

memory_limit = 512M

Place .user.ini in the same directory as your wp-config.php. It usually takes effect within a few minutes, but on some hosts you may need to wait for PHP-FPM to reload or request a restart through your control panel.

Fix 3: Use .htaccess (Apache only)

On Apache hosts that run PHP as a module, you can sometimes override the limit through .htaccess:

php_value memory_limit 512M

This won’t work on Nginx, LiteSpeed, or any setup running PHP-FPM. If the line produces a 500 error, remove it and use one of the other methods.

Fix 4: Ask your host

On managed WordPress hosts (Kinsta, WP Engine, SiteGround, and similar), the memory limit is often controlled by the control panel or support team, and self-edits are ignored. Open a ticket, tell them exactly what error you’re seeing, and ask for 256M or 512M depending on your workload. It’s a normal request.

When raising the limit isn’t the real fix

More memory hides problems that don’t want to be hidden. If you went from 128M to 512M and the site is still crashing, something is actively leaking. Common culprits:

  • A buggy or outdated plugin. Disable plugins one at a time (or use Query Monitor) and watch memory usage. Nine times out of ten, one plugin is doing something expensive on every request.
  • Huge autoloaded options. The wp_options table has an autoload column. If that field has grown to tens of megabytes, WordPress is loading all of it on every page. Audit with Query Monitor or a plugin like Advanced Database Cleaner.
  • Oversized media uploads. Someone upload a 40MB PNG and WordPress tries to generate eight resized variants in memory. Convert to JPEG/WebP and set reasonable upload limits.
  • A cron job running during peak traffic. wp-cron.php fires on regular page loads. If a heavy scheduled task lands on a checkout request, that request will be the one that dies.

Why this matters for ticketing sites specifically

A memory error on a content-only blog is annoying. A memory error on a ticketing site costs you real money and real trust. If the PDF generation fails, the attendee gets a confirmation without a ticket. If the email queue falls over, they get nothing at all. And because these failures are silent, you usually only find out when someone shows up at the door waving a phone that says “your order is complete” with no attachment.

This is exactly why we’ve always recommended setting WordPress memory to at least 256M before a ticket launch, and testing the full checkout flow end to end (purchase, email receipt, PDF ticket, QR check-in) under realistic load. A stress test that catches the problem costs you an afternoon. The same problem on sale day costs you sleep.

The short version

Check your current limit in Tools > Site Health. Aim for 256M minimum, 512M for busier sites. Set both WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT in wp-config.php. If WordPress can’t override PHP, raise it via .user.ini or your host’s control panel. And if more memory isn’t the real fix, go find the plugin, option, or cron job that’s actually leaking.

If you’re running Tickera or another WordPress ticketing system, make a habit of checking Site Health and your error logs a week before any ticket launch. Memory problems are silent, predictable, and completely avoidable once you know where to look.