- This topic has 6 replies, 2 voices, and was last updated 5 years, 4 months ago by
cully.
-
AuthorPosts
-
-
September 19, 2016 at 7:53 pm #7349
cullyParticipantI have a lot of WordPress posts (over 8,000). Each post has quite a few postmeta fields associated with it (over 100). Occasionally I need to bulk Trash posts. Before installing Piklist, I could select 20 posts and bulk “Move to Trash”, and it would take a couple seconds. After installing Piklist it takes a full minute, and sometimes times out. I can even try disabling Piklist, and it goes back to taking a couple seconds. I logged all of the database queries when Piklist is enabled and when it isn’t, and I see a TON of extra queries when Piklist is enabled. It looks like, when Piklist is enabled, for every post that’s moved to Trash, it will run a query like this for each postmeta field associated with the post:
INSERT INTO wp_postmeta (post_id, meta_key, meta_value) VALUES (<postid>, '<metakey>', '<metavalue>'Since I have so many postmeta fields associated with each post, this represents over 100 extra INSERT statements, for each post, during a “Move to Trash”.
When Piklist is disabled, these INSERTs go away. Any thoughts?
-
September 19, 2016 at 8:39 pm #7350
cullyParticipantOne thing I noticed is that the
<postid>in the INSERT statement above is not actually the ID of the post being deleted. It’s some otherclosedstatus post. -
September 19, 2016 at 8:53 pm #7351
cullyParticipantIt looks like the post with all the
INSERT INTO wp_postmetastatements is a revision of the post being moved to trash (i.e. thepost_parentis the post being moved to trash). I can only guess that Piklist is copying all the metadata over to the revision post when it’s moved to trash. Does that sound accurate? -
September 19, 2016 at 9:41 pm #7352
cullyParticipantI tracked down the problem. In
includes/class-piklist-revision.php, there are some hooks registered in thePiklist_Revisionconstructor:add_action('save_post', array('piklist_revision', 'save_post'), -1, 2); add_action('wp_restore_post_revision', array('piklist_revision', 'restore_revision'), 10, 2); add_filter('_wp_post_revision_fields', array('piklist_revision', '_wp_post_revision_fields'));If I comment those lines out, the “Move to Trash” action goes back to taking a couple seconds. Do you know if it’s safe to leave those commented out? If I can’t find a fix for this, I’m going to have to spend a lot of time modifying a plugin I made for a client, so it doesn’t use Piklist. Crossing my fingers for a simpler solution 🙂
-
September 22, 2016 at 12:26 pm #7374
SteveKeymasterWe’ll look into this. Commenting them out will just stop Piklist from saving custom field data in Post revisions.
-
September 22, 2016 at 12:29 pm #7375
SteveKeymasterWould you be able to send us an xml export of your posts so we can test a fix on this end? The standard WP exporter should work.
If you’re comfortable with that, please email to [email protected]
-
September 28, 2016 at 5:05 pm #7399
cullyParticipantSorry for the late reply. I was only using Piklist for a settings page on this project, so I just made a settings page manually, and forgot about this problem. Which, by the way, may be useful information for you all: I often find that I’m only using Piklist for settings pages. In those cases, it doesn’t seem necessary that Piklist manage custom fields in post revisions. Maybe a setting?
Anyway, I can’t send an export; it’s a client’s data, not my own. But I imagine you could simulate it by adding 100+ custom fields to posts and then trying to move 20 of them to Trash at a time. I’m not sure if the fact that the client also has like 8,000 posts has anything to do with it, so if 100+ fields doesn’t slow things down, then maybe add a bunch of posts.
Btw, once I created a custom settings page and uninstalled Piklist, it went back to taking only a second or two to move 20 posts to Trash.
Thanks for the great replies, by the way. Piklist has saved me a ton of time over quite a few projects. This is the only deal-breaker problem I’ve run into with it, and it’s likely somewhat of an unusual case.
-
-
AuthorPosts
- You must be logged in to reply to this topic.