Mass Deletion Problems with WordPress

I had a sort of hardcore testing running over the weekend, there was a bogus bugreport that made me uploading more than 80 thousand images to my blog in #13443. Now my Blog has way too many useless images, some thousand of them even unattached. I’d like to get rid of them all asap now. If you wonder how that turned out:

But it is not that easy. Even so the WordPress Backend has bulk actions (like delete multiple media files or classify a bunch of comments as spam), this bulk editing has some design flaws. I first run over those problems with mass-comment-editing in #11114 in November 2009. That time it was for comments. The main problem is, that the bulk HTML-Form is using the GET Method that creates too long URIs. Well, too long is relative because there is no limit in length as stated in RFC 2616 / 5.1.2, so HTTP does not limit the size of an URI to a certain number of Bytes. This normally is not supported by Servers, so the advice here is to choose the form submit method wisely.

So it is no wonder that on deleting a larger amount of media files turns out errors. Depending on the amount of files to delete you can encounter a varying number of error message. From reset connections, to a 414 Request-URI Too Large and I even got a 408 – website overloaded. It finally went with a number of 225 Media Items w/o Errors.

So which lesson to learn here? Use the right form method if you do not want to annoy your users. And in case you do not know the 408 error on, here is a quote:

Gosh Darnit!!!

We just got a “408 error” which means the website is overloaded.
We are working to fix this as soon as possible, please check back in a few minutes.

This entry was posted in Hacking The Core and tagged , , , , , , , , , , , . Bookmark the permalink.

4 Responses to Mass Deletion Problems with WordPress

  1. i also got this particular problem when developing wordpress in local host. it’s little bit f*ckup. It’s make original code harder to use the original wp in multi-roles and multi-states (logged in, unlogged in, and custom other state) environment. And make it worst, most of wordpress dashboard page can not be influence via hook (add_action and add_filters). so the problem will always exist until it spot by wp dev core and we can not fix it (mass deletion feature) without change the core file.

    • hakre says:

      Well that are two points:

      One is the problem that some fixes need change of core-files. I would say this is definitely true for this problem here. As long as this is not done right in core, the problem persists. Workaround for users is to limit the maximum to a number like 100 where those problems do not appear.

      The other point is what you write about the dashboard. I’m not that firm with it, but I think it will become more and more flexible. Just yesterday I ran over #13516 which will bring some traction to it. Additionally I would look for existing dashboard hooks, there should be some.

  2. Pingback: Zajímavé články o WordPressu (v angličtině) « Fórum podpory WordPressu

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.