Janis Elsts

1. The next update will include some minor configuration size improvements, though enabling compression in the “Settings” tab will still be more effective. However, if you’re using the free version, this won’t have any effect on DB entries that are exclusive to the Pro version.
2. Since you mentioned Kinsta earlier, here’s a tutorial from Kinsta.com on how to clean up plugin data in DB tables:
   https://kinsta.com/blog/uninstall-wordpress-plugin/#cleanup-tables-in-phpmyadmin
   In this case, you would need to search the wp_options table for ws_menu_editor_pro and delete that entry. It’s probably a good idea to back up the database first.

Ah, so you had the Pro version installed at some point. One thing to note is that installing and uninstalling the free version will not delete all Pro version data. It will only delete the settings that are also used by the free version.

In this case, you would need to install and uninstall the Pro version to clean up options like that. Or you could delete the ws_menu_editor_pro entry manually – that should be safe to do if the plugin has been uninstalled.

Not really. Please check your support threads. Its an evergreen and a lot of users stuck in this issue.

There are multiple user reports about the size of the menu configuration, and I do agree that it can get inconveniently large, especially on sites with lots of menu items and custom role settings. However, my impression was that this thread was about a different problem: settings not being cleaned up after uninstallation. I don’t think that has come up much before.

Again, what data are you referring to? Is there a specific auto-loaded option that’s not getting deleted? If you’re sure that it’s related to this plugin (options it creates usually have names starting with ws_ or ame_), you may be able to delete it manually using phpMyAdmin or another DB management tool.

Why all other plugins working so much smarter which also handle menue in wp?

I assume this is a rhetorical question.

• This reply was modified 3 weeks ago by Janis Elsts.

Normally, if you delete the plugin via the “Plugins -> Installed Plugins” page, it should automatically delete its settings. If you’ve already uninstalled the plugin using another method (e.g., by manually deleting the files), you could try installing it again (just install, don’t activate) and then deleting it as described above.

If that doesn’t help, could you be more specific about what the “auto load data” is? What is the largest table that you mentioned? Is there a specific table entry that’s very large?

Please verify that the option_value column in the wp_options table is also set to utf8mb4. Different tables and table columns can have different character sets, so even if the default character set for the database is correct, the character set of a specific column could be wrong/outdated.

For what it’s worth, as a developer, I would be happy to upgrade all my code to PHP 8.x and drop support for older PHP versions. However, the WordPress PHP version stats show that about 40% of users are still on those older versions, and less than 10% use an actively supported PHP version (currently that’s PHP 8.3 or 8.4). Perhaps it’s a chicken-and-egg problem, in a way.

In many cases, there’s a way to make the same code work without errors both in old and new PHP versions. This is unfortunately one of the exceptions. The gap between PHP 5.6 (2014) and PHP 8.4 (2024) might just be too large.

This is a tricky one since all those deprecation notices are triggered in a third-party library that this plugin uses: Freemius SDK. The problem has been reported to the author(s) of that library, but I suspect it’s not easy for them to fix because the proper solution would require raising PHP version requirements from PHP 5.6 to at least PHP 7.1. While that change would be fine for Error Log Monitor, it would still be a backwards compatibility break that could affect other users and developers.

Unfortunately, I don’t think there’s currently an easy way to fix those deprecation notices. However, as you noticed, they shouldn’t break anything; they just take up space in the log.

I’m guessing that you see this when trying to download the log. Based on the stack trace, this error is caused by a conflict with the wpDataTables plugin which uses an older version of the ZipStream-PHP library (Error Log Monitor uses ZipStream-PHP to compress the log for download).

Unfortunately, I don’t think I can currently offer a better workaround than temporarily deactivating the other plugin before downloading the log.

Unfortunately, it looks like those two specific stylesheets might be from the Pro version of the plugin, and www.ads-software.com forum rules do not allow using this forum to provide support for paid plugins. For issues with the Pro version, please use this contact form instead.

Thank you for the suggestion! Though AME currently has virtually no i18n support, if that support is added some day, it may be worth checking if it’s compatible with the translation plugin you mentioned.

If you haven’t already made many other menu changes that you don’t want to lose, the simplest solution might be to reset the menu configuration. One way to do that would be to uninstall and reinstall the plugin, which works because menu settings get deleted during uninstallation.

However, if that doesn’t work because the image hides the “Plugins” page or the deactivation link, you can also reset the configuration by using a special URL. Make sure you’re logged in as an admin, go to the WordPress dashboard, and add this to the page URL in the browser’s address bar:

?reset_admin_menu=1

So the full URL might look something like this:

https://example.com/wp-admin/index.php?reset_admin_menu=1

(Maybe without the index.php part, depending on how you got to the dashboard.) Then press “Enter” to go to that URL. This should reset the admin menu configuration.

As the error message says, the recommended fix is to convert the table to the?utf8mb4?character set. For example, you could try changing the table and column character sets with phpMyAdmin or a similar tool (it’s probably a good idea to back up your database first).

www.ads-software.com has some documentation on converting character sets, though unfortunately it looks a bit out of date:
https://codex.www.ads-software.com/Converting_Database_Character_Sets

Thank you, I have added that one to the list, too. It should also be hidden in the next version of the plugin.

This looks another case of a plugin adding some menu items and then removing them in a way that’s not fully compatible with Admin Menu Editor. It has to do with the technical details of how AME works, but the simple version is that AME takes a snapshot of the menu data at a certain point during a page load and any changes that other plugins make after that point don’t affect the final menu. This is not a bug in either plugin; it’s just a side-effect of certain technical constraints.

I’ll add “Elementor -> Connect” to the internal “these should always be hidden” list in AME. This item should stop showing up after the next plugin update.

Unfortunately, I don’t have the Pro version of Elementor, so I can’t do the same for “Notes Proxy”. Could you open that menu item, copy the item URL from the address bar, and paste it here? You can redact your site/domain name; I mainly need the part starting with /wp-admin/ to identify the menu item.

@gamerz In my testing, just #1 alone fixed the fatal error when using both plugins together.

However, #2 or some alternative is probably also necessary, since ELM loading scbFramework first means that your init function will run too early again, and the textdomain issue will reappear.