Back to Community
Home / Community / Plugin → Admin menu editor

Troubleshooting Large Database Size and Slow Performance in Admin Menu Editor

17 threads Sep 16, 2025 Plugin → Admin menu editor

Content

If you've noticed your WordPress database growing unexpectedly or experienced slow admin performance, the Admin Menu Editor plugin might be a contributing factor. A common issue reported by users is the plugin's ws_menu_editor option in the wp_options table (or ws_menu_editor_pro for Pro users) becoming excessively large and set to autoload, which can impact site performance.

Why This Happens

The Admin Menu Editor stores its entire configuration—including menu order, custom permissions, colors, and other settings for every admin menu item—as a single, serialized PHP array in the database. This data structure is efficient for parsing but not for storage space. On sites with many menu items or complex customizations, this single database entry can grow to several hundred kilobytes, far larger than typical options. In multisite installations, a rare bug or database corruption can sometimes cause thousands of duplicate entries to be created in the wp_sitemeta table.

Because this configuration is needed to render the admin menu correctly, the plugin sets this option to autoload='yes'. This means WordPress loads it into memory on every page load, which is efficient for few, small options. However, when a single option is very large, the time spent transferring this data from the database can become a performance bottleneck, especially on admin pages.

Common Solutions

1. Enable Configuration Compression

The plugin includes a built-in feature to compress its stored data, which can significantly reduce its size.

  1. In your WordPress admin, go to Settings > Menu Editor.
  2. Scroll down to the Debugging section.
  3. Check the box for "Compress menu configuration data that's stored in the database".
  4. Click Save Changes.
  5. Now, navigate to Admin Menu > Menu Editor.
  6. Click Save Changes again (you do not need to make any edits). This action rewrites the configuration to the database in its new, compressed format.

Note: There is a trade-off. Compression reduces the amount of data transferred from the database but adds CPU overhead for decompression on every page load. The net effect on performance can vary depending on your server.

2. Manually Disable Autoload

If compression doesn't help or isn't desired, you can change the option to not autoload. This will prevent the large data blob from being loaded on every frontend page view, but the plugin will still need to fetch it on every admin page, resulting in an extra database query.

You can change this setting using a database management tool like phpMyAdmin:

  1. Find the ws_menu_editor row in the wp_options table.
  2. Change the autoload value from yes to no.

Warning: Directly editing the database can break your site if done incorrectly. Always create a full backup first.

3. Clean Up Duplicate Multisite Entries (Advanced)

For multisite administrators who discover thousands of ws_menu_editor entries in the wp_sitemeta table:

  1. Export your menu editor settings from the plugin's Settings tab as a backup.
  2. Deactivate the Admin Menu Editor plugin network-wide.
  3. Use a tool like phpMyAdmin to run a repair on the wp_sitemeta table.
  4. Delete all duplicate ws_menu_editor entries, keeping only the one with the highest meta_id for each site ID.
  5. Reactivate the plugin.

4. Complete Uninstallation

To remove all plugin data from your database, the standard uninstallation process should be followed:

  1. Go to Plugins > Installed Plugins.
  2. Deactivate and then delete the Admin Menu Editor plugin.

According to the plugin's author, this should automatically remove its data. If the plugin was previously deleted manually (e.g., via FTP), reinstalling it and then deleting it properly through the Plugins page may trigger the cleanup routine.

Conclusion

The large database size is a known characteristic of how the Admin Menu Editor stores its complex configuration. For most users, enabling compression provides a good balance between size and performance. For those on high-traffic sites where every millisecond counts, carefully disabling autoload may be a viable alternative. Multisite administrators should be aware of the rare duplication bug and the procedure to clean it up.

Related Support Threads Support