Forum Replies Created
-
Posts
-
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.
I 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 🙂
It 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?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 otherclosedstatus post.Adding a Workflow fixed it. Seems strange that everything would basically work exactly the same before/after adding a Workflow, except for the tab names. Lots of extra overhead (creating all the workflow/tab files). Anyway, thanks for the great help!
@Steve Is that the case if I only want tabs? It seems to work great without defining a workflow, except I get that notice. Would a possible solution be to just check if that key isset before using it in
class-piklist-workflow.php?@Steve It happens when no other plugins are installed, and also with quite a few installed. The same thing happens in every project I’m using Piklist on. I don’t have a Workflow defined (I was under the impression I don’t need one for settings). Would that be a problem?
@jrcreative I don’t have a workflow, but I was under the impression you don’t need to explicitly define one for a settings page. Everything works fine without one, I just get that
Notice. In production those notices are turned off, so I don’t see them and everything works the way it should.
