Discussion:
Deleting a lot of posts/terms on plugin deactivation
Nikola Nikolov
2013-06-28 08:28:36 UTC
Permalink
Hello everyone,

I'm currently working on a (yet-another)multilingual plugin for WordPress.
I'm willing to add an uninstall functionality that would allow the user to
remove all data created by the plugin(so any options, custom meta, posts,
terms, etc). The plugin works by creating a duplicate post/term in a custom
post type/taxonomy for each enabled language.

I've noticed that when I have for instance 7 enabled languages and I want
to delete a bunch of posts, my WAMP installation would time-out at 60
seconds if I try to delete more than probably 10 posts, since I hook to the
delete_post hook and use wp_delete_post to remove the corresponding
translation posts - which means, that wp_delete_post is actually called for
up to 80 posts.

I realize that wp_delete_post is generally a heavy function, since deletes
all post meta, comments(?), etc.

What I'm wondering is whether I should use wp_delete_post or if there would
be a different approach to deleting multiple files with less load on the
server. Obviously if I stick to wp_delete_post(), I would use ajax-driven
uninstall process which would only delete a handful of posts at a time.

I assume one way to beat the timeout would be to try to use
set_time_limit() whenever I delete translation posts, but obviously I can't
use this solution for plugin uninstallation, since there could be a lot of
data(let's say a thousands-of-posts situation).

----

Nikola Nikolov
Mo Braga
2013-06-28 08:35:49 UTC
Permalink
If this is a one-off operation, use php directly, from the command line:

php <your-bulk-delete-program>.php

You may need to load WordPress in your program. For an example, see wp-cron.php

-----Original Message-----
From: wp-hackers [mailto:wp-hackers-***@lists.automattic.com] On Behalf Of Nikola Nikolov
Sent: 28 June 2013 09:29
To: wp-***@lists.automattic.com
Subject: [wp-hackers] Deleting a lot of posts/terms on plugin deactivation

Hello everyone,

I'm currently working on a (yet-another)multilingual plugin for WordPress.
I'm willing to add an uninstall functionality that would allow the user to remove all data created by the plugin(so any options, custom meta, posts, terms, etc). The plugin works by creating a duplicate post/term in a custom post type/taxonomy for each enabled language.

I've noticed that when I have for instance 7 enabled languages and I want to delete a bunch of posts, my WAMP installation would time-out at 60 seconds if I try to delete more than probably 10 posts, since I hook to the delete_post hook and use wp_delete_post to remove the corresponding translation posts - which means, that wp_delete_post is actually called for up to 80 posts.

I realize that wp_delete_post is generally a heavy function, since deletes all post meta, comments(?), etc.

What I'm wondering is whether I should use wp_delete_post or if there would be a different approach to deleting multiple files with less load on the server. Obviously if I stick to wp_delete_post(), I would use ajax-driven uninstall process which would only delete a handful of posts at a time.

I assume one way to beat the timeout would be to try to use
set_time_limit() whenever I delete translation posts, but obviously I can't use this solution for plugin uninstallation, since there could be a lot of data(let's say a thousands-of-posts situation).

----

Nikola Nikolov
_______________________________________________
wp-hackers mailing list
wp-***@lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-hackers

________________________________

Confidentiality notice
This communication is from LBi Ltd, a private limited company registered in Scotland with registered number SC177425 having its registered office at 51 Timberbush, Edinburgh, EH6 6QH.
This electronic message contains information which may be privileged and confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or e-mail as above immediately.
Nikola Nikolov
2013-06-28 09:07:57 UTC
Permalink
It should be a one-time operation indeed, but the question is how would I
use the command-line from inside PHP itself - the idea is that (for
instance)the user would go to a page and click a button that will then
trigger the uninstall process.

It should work on various set-ups and in some cases(well maybe most, I'm
not sure), you won't be able to execute CLI commands from PHP itself, since
that will be disabled.
Post by Mo Braga
php <your-bulk-delete-program>.php
You may need to load WordPress in your program. For an example, see wp-cron.php
-----Original Message-----
Behalf Of Nikola Nikolov
Sent: 28 June 2013 09:29
Subject: [wp-hackers] Deleting a lot of posts/terms on plugin deactivation
Hello everyone,
I'm currently working on a (yet-another)multilingual plugin for WordPress.
I'm willing to add an uninstall functionality that would allow the user to
remove all data created by the plugin(so any options, custom meta, posts,
terms, etc). The plugin works by creating a duplicate post/term in a custom
post type/taxonomy for each enabled language.
I've noticed that when I have for instance 7 enabled languages and I want
to delete a bunch of posts, my WAMP installation would time-out at 60
seconds if I try to delete more than probably 10 posts, since I hook to the
delete_post hook and use wp_delete_post to remove the corresponding
translation posts - which means, that wp_delete_post is actually called for
up to 80 posts.
I realize that wp_delete_post is generally a heavy function, since deletes
all post meta, comments(?), etc.
What I'm wondering is whether I should use wp_delete_post or if there
would be a different approach to deleting multiple files with less load on
the server. Obviously if I stick to wp_delete_post(), I would use
ajax-driven uninstall process which would only delete a handful of posts at
a time.
I assume one way to beat the timeout would be to try to use
set_time_limit() whenever I delete translation posts, but obviously I
can't use this solution for plugin uninstallation, since there could be a
lot of data(let's say a thousands-of-posts situation).
----
Nikola Nikolov
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
________________________________
Confidentiality notice
This communication is from LBi Ltd, a private limited company registered
in Scotland with registered number SC177425 having its registered office at
51 Timberbush, Edinburgh, EH6 6QH.
This electronic message contains information which may be privileged and
confidential. The information is intended to be for the use of the
individual(s) or entity named above. If you are not the intended recipient
be aware that any disclosure, copying, distribution or use of the contents
of this information is prohibited. If you have received this electronic
message in error, please notify us by telephone or e-mail as above
immediately.
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
Matthias Breuer
2013-06-28 11:53:02 UTC
Permalink
I think the best way is using AJAX to delete the posts in batches. A bonus for this method is, that the user has visual feedback about the process. Much better than waiting for a page refresh that might not even happen.

Best,
Matthias
Post by Nikola Nikolov
It should be a one-time operation indeed, but the question is how would I
use the command-line from inside PHP itself - the idea is that (for
instance)the user would go to a page and click a button that will then
trigger the uninstall process.
It should work on various set-ups and in some cases(well maybe most, I'm
not sure), you won't be able to execute CLI commands from PHP itself, since
that will be disabled.
Post by Mo Braga
php <your-bulk-delete-program>.php
You may need to load WordPress in your program. For an example, see wp-cron.php
-----Original Message-----
Behalf Of Nikola Nikolov
Sent: 28 June 2013 09:29
Subject: [wp-hackers] Deleting a lot of posts/terms on plugin deactivation
Hello everyone,
I'm currently working on a (yet-another)multilingual plugin for WordPress.
I'm willing to add an uninstall functionality that would allow the user to
remove all data created by the plugin(so any options, custom meta, posts,
terms, etc). The plugin works by creating a duplicate post/term in a custom
post type/taxonomy for each enabled language.
I've noticed that when I have for instance 7 enabled languages and I want
to delete a bunch of posts, my WAMP installation would time-out at 60
seconds if I try to delete more than probably 10 posts, since I hook to the
delete_post hook and use wp_delete_post to remove the corresponding
translation posts - which means, that wp_delete_post is actually called for
up to 80 posts.
I realize that wp_delete_post is generally a heavy function, since deletes
all post meta, comments(?), etc.
What I'm wondering is whether I should use wp_delete_post or if there
would be a different approach to deleting multiple files with less load on
the server. Obviously if I stick to wp_delete_post(), I would use
ajax-driven uninstall process which would only delete a handful of posts at
a time.
I assume one way to beat the timeout would be to try to use
set_time_limit() whenever I delete translation posts, but obviously I
can't use this solution for plugin uninstallation, since there could be a
lot of data(let's say a thousands-of-posts situation).
----
Nikola Nikolov
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
________________________________
Confidentiality notice
This communication is from LBi Ltd, a private limited company registered
in Scotland with registered number SC177425 having its registered office at
51 Timberbush, Edinburgh, EH6 6QH.
This electronic message contains information which may be privileged and
confidential. The information is intended to be for the use of the
individual(s) or entity named above. If you are not the intended recipient
be aware that any disclosure, copying, distribution or use of the contents
of this information is prohibited. If you have received this electronic
message in error, please notify us by telephone or e-mail as above
immediately.
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
Nikola Nikolov
2013-06-28 12:07:52 UTC
Permalink
Yeah - I guess that this will be my choice at the end - just wanted to
check if someone else has any better ideas.

I'll also have to look into not timing out the Posts page when the user
batch-deletes multiple posts/pages. But that's another story.
Post by Matthias Breuer
I think the best way is using AJAX to delete the posts in batches. A bonus
for this method is, that the user has visual feedback about the process.
Much better than waiting for a page refresh that might not even happen.
Best,
Matthias
Post by Nikola Nikolov
It should be a one-time operation indeed, but the question is how would I
use the command-line from inside PHP itself - the idea is that (for
instance)the user would go to a page and click a button that will then
trigger the uninstall process.
It should work on various set-ups and in some cases(well maybe most, I'm
not sure), you won't be able to execute CLI commands from PHP itself,
since
Post by Nikola Nikolov
that will be disabled.
Post by Mo Braga
php <your-bulk-delete-program>.php
You may need to load WordPress in your program. For an example, see wp-cron.php
-----Original Message-----
Behalf Of Nikola Nikolov
Sent: 28 June 2013 09:29
Subject: [wp-hackers] Deleting a lot of posts/terms on plugin
deactivation
Post by Nikola Nikolov
Post by Mo Braga
Hello everyone,
I'm currently working on a (yet-another)multilingual plugin for
WordPress.
Post by Nikola Nikolov
Post by Mo Braga
I'm willing to add an uninstall functionality that would allow the user
to
Post by Nikola Nikolov
Post by Mo Braga
remove all data created by the plugin(so any options, custom meta,
posts,
Post by Nikola Nikolov
Post by Mo Braga
terms, etc). The plugin works by creating a duplicate post/term in a
custom
Post by Nikola Nikolov
Post by Mo Braga
post type/taxonomy for each enabled language.
I've noticed that when I have for instance 7 enabled languages and I
want
Post by Nikola Nikolov
Post by Mo Braga
to delete a bunch of posts, my WAMP installation would time-out at 60
seconds if I try to delete more than probably 10 posts, since I hook to
the
Post by Nikola Nikolov
Post by Mo Braga
delete_post hook and use wp_delete_post to remove the corresponding
translation posts - which means, that wp_delete_post is actually called
for
Post by Nikola Nikolov
Post by Mo Braga
up to 80 posts.
I realize that wp_delete_post is generally a heavy function, since
deletes
Post by Nikola Nikolov
Post by Mo Braga
all post meta, comments(?), etc.
What I'm wondering is whether I should use wp_delete_post or if there
would be a different approach to deleting multiple files with less load
on
Post by Nikola Nikolov
Post by Mo Braga
the server. Obviously if I stick to wp_delete_post(), I would use
ajax-driven uninstall process which would only delete a handful of
posts at
Post by Nikola Nikolov
Post by Mo Braga
a time.
I assume one way to beat the timeout would be to try to use
set_time_limit() whenever I delete translation posts, but obviously I
can't use this solution for plugin uninstallation, since there could be
a
Post by Nikola Nikolov
Post by Mo Braga
lot of data(let's say a thousands-of-posts situation).
----
Nikola Nikolov
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
________________________________
Confidentiality notice
This communication is from LBi Ltd, a private limited company registered
in Scotland with registered number SC177425 having its registered
office at
Post by Nikola Nikolov
Post by Mo Braga
51 Timberbush, Edinburgh, EH6 6QH.
This electronic message contains information which may be privileged and
confidential. The information is intended to be for the use of the
individual(s) or entity named above. If you are not the intended
recipient
Post by Nikola Nikolov
Post by Mo Braga
be aware that any disclosure, copying, distribution or use of the
contents
Post by Nikola Nikolov
Post by Mo Braga
of this information is prohibited. If you have received this electronic
message in error, please notify us by telephone or e-mail as above
immediately.
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
Ryan McCue
2013-06-30 06:39:41 UTC
Permalink
Post by Nikola Nikolov
Yeah - I guess that this will be my choice at the end - just wanted to
check if someone else has any better ideas.
Your best bet is to offload this onto wp-cron, which runs without a
timelimit (similar to CLI) in the background.
--
Ryan McCue
<http://ryanmccue.info/>
Matthias Breuer
2013-06-30 18:28:01 UTC
Permalink
Post by Ryan McCue
Post by Nikola Nikolov
Yeah - I guess that this will be my choice at the end - just wanted to
check if someone else has any better ideas.
Your best bet is to offload this onto wp-cron, which runs without a
timelimit (similar to CLI) in the background.
I always thought wp-cron is running as a synchronous process when not called via real cronjobs. Is it done asynchronously?
Post by Ryan McCue
--
Ryan McCue
<http://ryanmccue.info/>
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
Chris McCoy
2013-06-30 20:36:34 UTC
Permalink
wp-cron wont run unless someone actually hits the site right? so if you
have zero visitors it wont run? with crontab it will.

maybe i am mistaken.
Post by Matthias Breuer
Post by Ryan McCue
Post by Nikola Nikolov
Yeah - I guess that this will be my choice at the end - just wanted to
check if someone else has any better ideas.
Your best bet is to offload this onto wp-cron, which runs without a
timelimit (similar to CLI) in the background.
I always thought wp-cron is running as a synchronous process when not
called via real cronjobs. Is it done asynchronously?
Post by Ryan McCue
--
Ryan McCue
<http://ryanmccue.info/>
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
Dobri
2013-07-01 13:00:19 UTC
Permalink
wp-cron fires up on page request only (kinda the only way with just PHP if you think hard enough) so yes, in a way it's synchronous but at the same time no, since wordpress fires up a separate non-blocking (asynchronous) request to wp-cron so as to not make the original request wait for time-consuming cron jobs if such happen to exist the moment someone accessed the server. You know, user experience and stuff. But yes, Chris had a good point, 0 visitors means no jobs being done. I've seen it happen but there are workarounds.

~Dobri
Post by Matthias Breuer
Post by Ryan McCue
Post by Nikola Nikolov
Yeah - I guess that this will be my choice at the end - just wanted to
check if someone else has any better ideas.
Your best bet is to offload this onto wp-cron, which runs without a
timelimit (similar to CLI) in the background.
I always thought wp-cron is running as a synchronous process when not called via real cronjobs. Is it done asynchronously?
Post by Ryan McCue
--
Ryan McCue
<http://ryanmccue.info/>
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
Brian Layman
2013-07-01 17:18:52 UTC
Permalink
Post by Matthias Breuer
Post by Ryan McCue
Post by Nikola Nikolov
Yeah - I guess that this will be my choice at the end - just wanted to
check if someone else has any better ideas.
Your best bet is to offload this onto wp-cron, which runs without a
timelimit (similar to CLI) in the background.
I always thought wp-cron is running as a synchronous process when not called via real cronjobs. Is it done asynchronously?
Back in the 2.1 era or so you would have been correct. Back then,
whichever unlucky visitor triggered all the work was the one that got a
slow page load. Now, instead of processing cron directly, a separate
web call is made from the code using wp_remote_post() to trigger the
processing of a cron batch. That way all of the cron steps are executed
asynchronously to any the visitor's session.

Brian Layman
Matthias Breuer
2013-07-01 18:50:42 UTC
Permalink
It's always delighting what you can learn reading through core sources.
Post by Matthias Breuer
Post by Ryan McCue
Post by Nikola Nikolov
Yeah - I guess that this will be my choice at the end - just wanted to
check if someone else has any better ideas.
Your best bet is to offload this onto wp-cron, which runs without a
timelimit (similar to CLI) in the background.
I always thought wp-cron is running as a synchronous process when not called via real cronjobs. Is it done asynchronously?
Back in the 2.1 era or so you would have been correct. Back then, whichever unlucky visitor triggered all the work was the one that got a slow page load. Now, instead of processing cron directly, a separate web call is made from the code using wp_remote_post() to trigger the processing of a cron batch. That way all of the cron steps are executed asynchronously to any the visitor's session.
Brian Layman
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
Loading...