Viewing 6 reply threads
  • Author
    Posts
    • #7349
      cully
      Participant

      I 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?

    • #7350
      cully
      Participant

      One 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 other closed status post.

    • #7351
      cully
      Participant

      It looks like the post with all the INSERT INTO wp_postmeta statements is a revision of the post being moved to trash (i.e. the post_parent is 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?

    • #7352
      cully
      Participant

      I tracked down the problem. In includes/class-piklist-revision.php, there are some hooks registered in the Piklist_Revision constructor:

      
      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 🙂

    • #7374
      Steve
      Keymaster

      We’ll look into this. Commenting them out will just stop Piklist from saving custom field data in Post revisions.

    • #7375
      Steve
      Keymaster

      Would 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]

    • #7399
      cully
      Participant

      Sorry 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.

Viewing 6 reply threads
  • You must be logged in to reply to this topic.