WordPress: fix a write rejected by max_allowed_packet

Recognize a rejected SQL packet during a write

Saving settings, regenerating data, or running a process fails with “Got a packet bigger than max_allowed_packet.” The SQL engine or client encountered an oversized packet and may close the connection. A statement sent or a row received may be affected; the database’s total size does not directly explain this rejection. The message “MySQL server has gone away” alone is not enough to attribute a failure to this limit.

The goal is a complete write with a controlled volume, followed by correct reading of the data. The first approach reduces what the component gathers into a single operation. The second adjusts the SQL limit when the need is legitimate and measured. Both decisions require identifying the failing query, not just the screen displaying the error.

This guide addresses a write performed by WordPress or a component. A full SQL import that exceeds a timeout or file limit requires a different procedure. On managed hosting, engine settings belong to the provider. In multisite, check which table and subsite are affected before changing data or a shared service.

Suspend retries and preserve the affected data

Stop repeated retries as soon as the message is identified. A process handling several items may have partially succeeded before the final rejection. Note completed and still-uncertain items through the interface, without assuming that a 500 error means no writes occurred at all. Keep the time and the first useful SQL message.

Prepare an appropriate backup of the data or database and a copy of the installation for testing. If the component offers an export of its settings, keep it separately. A WordPress content export does not necessarily cover an internal option or processing state. Disable outbound messages and commercial operations on the copy.

Choose a limited, reversible write on the copy to reproduce the failing action, with an expected result that is easy to read back. Simply reading settings does not necessarily reproduce a saving error. Keep a backup of the reference value. Do not delete a large row from the options table: its role and whether it can be rebuilt must first be established with its owner.

Separate SQL packet size, PHP memory, and form size

max_allowed_packet concerns communication between an SQL client and the server, as well as certain operations on large strings. It is neither the maximum upload file size nor the number of fields a form sends to PHP. Increasing post_max_size, WordPress memory, or max_input_vars does not automatically raise this limit.

The client and server may have their own constraints. Changing a value in the mysql command-line program does not by itself change the driver used by PHP. Conversely, a raised server setting may leave another limit along the application’s route. The documentation and exact engine context are needed to choose the right setting.

Keep the statement and table names appearing in the log, masking private values. An option stored in a single field can become very large; a much larger database as a whole may still operate with smaller queries. What matters is the volume of the failing operation, not an assumed global quota for posts or media.

Read the effective server and session limits

With authorized SQL access, open phpMyAdmin from the hosting panel, select the database on the left, then SQL. The read-only query below displays the version, current database, and global and session limits. It changes nothing. Keep the connection endpoint’s identity and the time, especially if the installation uses a proxy or multiple nodes.

The SQL manager’s session is not necessarily WordPress’s session. An already-connected application or another endpoint may still use a different context. Ask the administrator to correlate this reading with the connection PHP actually uses. A number displayed in a panel without that context does not validate the fix.

On WordPress.com, documented phpMyAdmin access is reserved for Business and Commerce plans: Hosting Dashboard, site, Settings, Server, Database, Open phpMyAdmin. This access does not grant administration of the SQL service. On a shared or managed plan, ask for the value applied to the site’s connection and the actual possibilities for changing it. There is no universal WordPress checkbox for this option; a plugin cannot grant itself server privileges.

1. Confirm the server, database, and your read permission.
2. Run the query and keep the values in bytes.
3. Note any difference between them and WordPress’s connection context.
4. If the read is denied, keep the denial for the administrator without expanding the application account’s privileges.

SELECT VERSION() AS version_serveur,
       DATABASE() AS base_courante,
       @@GLOBAL.max_allowed_packet AS limite_globale,
       @@SESSION.max_allowed_packet AS limite_session;

Measure an already-stored option without displaying its contents

If the log precisely identifies an option, measure its existing value with a targeted read-only query. Replace prefixe_options with the actual table name and option_confirmee with the confirmed option name. In multisite, subsite options and network options do not necessarily share the same schema: the query below targets only a site options table. Have the query adapted if the data is in a network table or a plugin-specific table.

OCTET_LENGTH measures bytes, not characters. The query does not display the option’s private contents. This stored size is not the size of the packet sent: the SQL statement, its escaping, and other values add volume; the rejected new data may also be larger. The result helps explain growth without sizing the limit exactly from this number alone.

If no row appears, do not create the option to test it. Check its name and owner. If the data is in a plugin-specific table, adapt the observation with the person responsible. Do not rank all sensitive values while displaying their full contents to save time.

SELECT option_name, OCTET_LENGTH(option_value) AS octets
FROM prefixe_options
WHERE option_name = 'option_confirmee';

Identify the component with Query Monitor if the response remains available

The existing PHP or SQL log remains the first lead without a new plugin. On the copy, Query Monitor, a free plugin developed by John Blackbourn, can connect a query to its caller when the response remains inspectable. The verified listing specifies version 4.1.1, WordPress 6.3 and PHP 7.4 minimum, with declared compatibility up to WordPress 7.1.4. These minimums are not a recommendation to retain an old PHP version.

Query Monitor displays queries from the current page load, not the history of every query on the site. After a redirect, the destination page’s panel does not prove what happened during the previous save. A background task or an interrupted response may also escape this workflow. Do not conclude that no error occurred if its panel is empty; keep the log associated with the action. Displayed SQL values may be private.

1. On the compatible copy, open Plugins > Add New Plugin, search for Query Monitor and verify John Blackbourn, then choose Install Now and Activate. In multisite, involve the network administrator if installation or diagnostic access is restricted.
2. Reproduce the authorized reference write once; open Query Monitor’s numbered menu in the admin bar if that response allows it.
3. View Database Queries, then Query Errors, visible when an SQL error has been collected. Record the caller and component without disclosing the query values.
4. Correlate this information with the log and exact time. If the error belongs to another request or remains invisible, return to the log and the component developer.
5. After diagnosis, open Plugins > Installed Plugins and deactivate Query Monitor at the level where it was activated.

Reduce a batch when the component supports it

The first approach is appropriate if the tool documents a batch size, processing pagination, or per-item saving. From its settings screen on the copy, keep the initial value, then choose a smaller batch. Use the intended mechanism; closing a visual panel or selecting fewer rows does not guarantee a smaller SQL query.

Repeat the same reference case and check the data after reopening it. If the small batch works, compare the log and processed volume before continuing. Keep a record of completed items to avoid duplicate processing on resumption. The expected result is a series of bounded writes, each complete, with consistent final coverage.

1. Record the initial batch size and processing state.
2. Reduce it through the component’s documented option on the copy.
3. Run one reference batch and read back its result.
4. Check whether the operation nevertheless continues to rewrite an accumulated option that keeps growing.
5. If reducing the batch does not affect the packet, restore the setting and move on to the data owner or SQL sizing.

Fix data that grows with every operation

A smaller batch may fail after a few passes if the tool gathers all results into the same option. In that case, raising the limit does not control growth. Have the data’s role identified: history, rebuildable cache, processing state, or business information. Its name and size alone do not determine whether it can be deleted.

Look in the component’s documentation for retention, targeted cleanup, or an official fix. On the copy, export or back up the data, then apply only that documented mechanism. Check what is retained and what must be rebuilt. Cleanup that erases progress state may require a specific resumption process without repeating already-completed actions.

Do not truncate a serialized value in the middle or replace its contents with an empty string to reduce bytes. Do not simply disable its autoload thinking this will reduce the next write: that setting concerns loading, not necessarily the volume saved. If the storage structure is responsible, the developer must fix the mechanism before processing resumes at scale.

Adjust the SQL limit for a legitimate, measured need

The second approach belongs to the authorized SQL administrator. It is suitable for a bounded need exceeding the effective limit. On MySQL 8.4, SET GLOBAL requires SYSTEM_VARIABLES_ADMIN, or the older, now-deprecated SUPER privilege; this privilege must not be added to the WordPress account. The change affects the SQL service, potentially shared by several installations, not just the database selected in phpMyAdmin.

The example below temporarily sets 64 MiB, or 67,108,864 bytes. This is already the documented default in MySQL 8.4; MariaDB documentation specifies 16 MiB on the server side. These are reference points, not guaranteed values for your plan. Do not run the example if your limit is already equal or higher. The selected value must meet the measured need and available resources.

In the administrative SQL session for the identified service, first keep the initial value, apply the authorized change, then read it back. The example’s result should be 67108864. A permission denial stops this approach; it does not justify changing the application account. SET GLOBAL alone does not persist after a restart. For a lasting fix, the administrator uses the service’s settings or configuration; MySQL and MariaDB do not all offer the same mechanisms.

1. Compare the need with the limits actually reached, on both server and client.
2. Keep the initial value and the scope affecting other consumers.
3. Apply a proportionate value through authorized service management.
4. Open new test connections and read their value before the WordPress test.
5. To undo the change, reuse SET GLOBAL with the recorded initial number, not DEFAULT, which might differ. Also restore the persistent setting if you changed it, then check new connections.

SET GLOBAL max_allowed_packet = 67108864;
SELECT @@GLOBAL.max_allowed_packet AS nouvelle_limite;

Check new connections and the PHP client

An already-open connection may retain its old context after a global change. Close and reopen the test session, then rerun the global and session read from “Read the effective server and session limits.” Next have the connection PHP actually uses checked: reopening phpMyAdmin does not renew the application’s connection. MySQL documents the session value as read-only; MariaDB likewise describes it as not dynamically modifiable. Do not inject SET SESSION into WordPress.

If the server reports a sufficient limit but the write still fails, examine the client and route. A successful test with the mysql program does not automatically validate the PHP driver. An SQL proxy, persistent connection, or different endpoint may require its own check. Have the exact context recorded instead of restarting every service at random.

Do not change connection timeouts, InnoDB logs, and several memory limits at once merely because a forum suggests them. Each change must address evidence. The expected result is an application connection using the intended limit without changing data access privileges. If that evidence is missing, keep the reduced case and continue connection diagnosis before another large operation.

Validate the write and then the usual volume

On the copy, repeat the failing reference case with the same data and the corrected configuration. Check the log at that time and reopen the screen to read the value actually saved. A success notification is not enough if the process continues writing in the background. Check the point where the previous operation stopped.

Then move to a representative volume, with external effects disabled and completed items tracked. Check data at the beginning and end, along with data that should not have changed. If the solution relies on batches, together they must cover the need without allowing a cumulative option to grow back to the limit.

Also observe load and connection errors. Raising a limit does not guarantee that the server has resources suitable for every simultaneous write. Keep the validated sizing and remove unnecessary diagnostic settings. A packet repair is complete when the expected writes are complete and readable, not merely when the old message disappears for a small operation.

Recover partial results with the data owner

If previous tests left incomplete results, separate their recovery from the limit fix. Record the current state and already-completed items. Some components can resume a queue; others rebuild their history or rewrite a complete set. Use their documented mechanism instead of replaying every action from the beginning.

For important overwritten values, prepare targeted recovery from the backup. A full database restore could delete newer posts, accounts, or orders. Simply restoring the old SQL limit does not undo writes made with the new value. Configuration rollback and data rollback each need their own scope.

If a cleanup operation was tried on the copy, keep its export and result before reproducing it elsewhere. Do not transfer an entire staging table to production without understanding identifiers, dependencies, and changes since then. The component owner must be able to explain what will be retained, rebuilt, or lost during recovery.

Keep size bounded instead of repeatedly raising limits without measurement

Document the query involved, its owning component, the measured data, and the limit used by the site’s connection. Keep the initial value and persistent method if a server change was chosen. When a component adds history or gathers new results, check its growth again on the copy.

Appropriate retention or batch writes can prevent ever more information from being concentrated in one packet. These changes belong to the component’s storage mechanism; they must not be improvised by directly editing its serialized values. Data must be identified as rebuildable before its cleanup is used.

To request a fix, provide the time, redacted SQL message, table, confirmed data name, and useful volumes. Add the difference between a small batch and the usual volume, connection values, and effects of the attempted fix. Do not share the complete query if it contains site content. This record helps choose between application optimization and justified SQL sizing without turning the repair into a series of blind increases.

Determine whether a small batch really reduces the next write

Prepare a three-batch record on the copy, listing each batch’s item count, time, confirmed option size before processing, and size afterward. Use the OCTET_LENGTH read already presented; do not copy the option contents.

Fictional example: three batches of ten items take the option from 2 to 4, then 6, then 8 MiB. The batch stays small, but the rewritten history grows each time. Further reducing the batch may only postpone failure. Conversely, per-item storage with bounded progress state may maintain a stable size; this must be verified, not inferred from a “batch” button.

The developer must then separate business data to retain, a log subject to retention, and the resume marker. The fix is not to truncate the existing value: it must involve a compatible component change and a test of resumption after interruption. Readers without code access should send this record to the vendor with the component version and first SQL message. Query Monitor helps identify the caller when it can observe the query; it is not a storage-rewriting tool. Return to the initial batch setting if the test brings no benefit.