Skip to content

When saving menus, conditional purging greatly impacts performance. #112

Open
@greenbeemedia

Description

@greenbeemedia

Apparently since menus are made up of many posts, and the purge function of the helper is post type agnostic, when you update a menu, the plug-in will generate many purge requests depending on what settings you have, seriously slowing down the saving process for menus.

When the menu is large enough it results in excessively long execution times and time-outs if you are using nginx or php-fpm. With the plug-in turned off, it's near instantaneous saving.

I think that perhaps this plugin should discriminate against trying to purge for every menu item type post deleted or modified while saving or updating menus. It would make much more sense to purge the home page for instance, only after all the menu items that have been update/deleted/added, and to do so only once, rather than what it is doing now, for every menu item.

I've had to disable the plug-in to work on my menus, I think I will probably write you guys a patch to exclude menu post types from this kind of behaviour. Spent over 3 hours today diagnosing this thinking it was a problem with my nginx setup and max_input_vars in php.ini.

It might even make sense to be able to choose default/specific behaviours based on the post_type. For instance, if your site is hosting WooCommerce, it would make absolutely no sense to purge the home page or the post itself if you've added a weborder. Order changes in the back-end have no impact on the website's front-end unless the user is logged in, in most cases. This should definitely be a feature, otherwise it will be very cumbersome to use this plug-in on a high availability e-commerce site.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions