How to gracefully handle WordPress plugin activation errors?Posted on February 25th, 2012 No comments
Things I learned while attempting to build a custom WordPress plugin…
A) The documentation is far from clear.
B) There’s lots of ways of doing it
C) Many blog posts exist around the net with tutorials and examples, and many of them are outdated
D) Proper, logical coding practices and assumptions do not work.
E) You have to just mess with it until it works.
“The world is already flooded with blog posts about how great W3 Total Cache is and how terrific Super Cache is and how fantastic Bat Cache is. Surely one of these will work for me,” I think to myself.
But alas, I tested using each of these plugins on my site and none of them really did the trick. W3 Total Cache actually broke my theme completely and threw errors; Super Cache didn’t help much either. And Bat Cache was just complete rubbish. Discouraged, I decided to write my own plugin from scratch. So, off I go.
I’ll write a custom caching plugin that uses Memcache.
After a week of off-and-on development, I got my caching plugin working extremely well: What was up to 15 seconds is now sub 300ms! Same page, same WP Multi-site, one plugin with only about 300 lines of code. But it only works in a highly-controlled environment. I want to put it up on the WordPress site so others can use it, but before I can release it into the wild, I need to make sure it’s really polite about errors and easy to work with.
Specifically, I have these 3 simple goals to finish it up:
1) If you don’t have the Memcache extension installed when you try to activate the plugin, it needs to display a warning message about missing extension;
2) I want to use the standard h2 error message to display this error to the user; and
3) I want the plugin to remain deactivated if activation fails.
You would think the WordPress Codex, Plugin Resources and Plugin API Documentation would be chock full of great examples for Plugin developers, wouldn’t you? I did, too, but unfortunately this just isn’t the case.
I’ll give examples of A through E above, and hopefully explain how I was able to achieve the proper implementation points of 1, 2 and 3.
How do you handle WordPress Plugin Activation errors gracefully?
This post says to use the wp_die( ) function.
I tried that and it actually does prevent the plugin from getting activated.
This post suggests that you should just let the fatal error happen and display a slightly better error message in a status box. Terrible idea, IMO.
Better to use this. Render red error messages in h2′s like this post shows. I’m trying to combine these concepts into a single, elegant solution and having a real rough time of it.
I think the only way to do it is like HungryCoder says, you have to freaking ob_start and catch the error with output buffering…
Leave a reply