Joost de Valk

Ari Stathopoulos

Progress Planner

Filip Ilić

This plugin tracks which of the autoloaded options are used on a page, and stores that data at the end of page render. It keeps an array of options that it has seen as being used. On the admin page, it compares all the autoloaded options to the array of stored options, and shows the autoloaded options that have not been used as you were browsing the site. If you’ve been to every page on your site, or you’ve kept the plugin around for a week or so, this means that those options probably don’t need to be autoloaded.
<h3>How to use this plugin</h3>
Install this plugin, and go through your entire site. Best is to use it normally for a couple of days, or to visit every page on your site and in your admin manually. Then go to the plugin’s settings screen, and go through the unused options. You can either decide to remove an unused option (they might for instance be for plugins you no longer use), or to set it to not autoload. The latter action is much less destructive: it’ll still be there, but it just won’t be autoloaded.

AAA Option Optimizer

And I love the speed in which improvements are made :)

Great tool to minimize autoloaded data size


I wonder how on earth a plugin tha promises to optimize the wp_options tables, stores 25MB of data in the option_value !!!! Maybe the guy who developed it does not understand the fundamentals of the internal database optimizers but such a huge deviation, totally ruins MariaDBs/MySQL internal optimizer. You see optimizers work on the assumption that in a table, the fields have somewhat related sizes. For more details please go to MariaDB Jira and check for cases MDEV-34097 and MDEV 32663If you add records with huge sizes (say > 100k) in wp_options table where each option is usually less than 30Bytes, then you have an issue. In our case the issue was caused by the very plugin that we used to monitor our options (that are by and large incorrect). Avoid it at all costs.


A joke!!!

Plugin that tracks autoloaded options usage and allows the user to optimize them.

NicolasKulka

Amaury Balmer

Maxime Culea

BE API

Are you using Advanced Custom Fields for option pages and Polylang for your multilingual site?
Polylang does not natively support ACF Option Pages, so option values are shared across all languages. This plugin improves that: once activated, you can set different values per language. Values are stored per language in the database and the correct one is loaded according to the current Polylang language. If a value isn’t set for a language, the “All languages” value is used by default.
Note: On activation, existing option values become temporarily unavailable (but remain in the database); you can recover them by deactivating the plugin. To edit options for a language, use the Polylang language switcher in the admin bar before opening the options page.
Requirements: WordPress 6.0+, PHP 7.4–8.4, <a href="https://www.advancedcustomfields.com/pro" rel="nofollow ugc">Advanced Custom Fields</a> 5.6.0+, <a href="https://polylang.pro/" rel="nofollow ugc">Polylang</a> (tested up to 3.7.7).
For full documentation (usage, filters, API, excluding pages, default fallback, loading untranslated values), see the <a href="https://github.com/BeAPI/acf-options-for-polylang#readme" rel="nofollow ugc">project README on GitHub</a>.

ACF Options For Polylang

Improves Polylang by adding per-language support for ACF options pages—each language can have its own option values.

AAA Option Optimizer vs ACF Options For Polylang