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…
Posted on February 18th, 2012 No comments
See, nobody’s perfect. Not even Facebook. (Ha! Far from it, right?)
I’m not able to post an update status at the moment. I thought I’d document it.
Not bad, though, Facebook IT team, I think you have, what, 99.9999% uptime?
Posted on February 4th, 2012 2 comments
Chances are you’ve heard of Memcache. Tons of websites use it to speed up page load times. I often say that Redis is like Memcache on steroids. You may not have heard of Redis, but if you’re using Memcache or APC, you should see how Redis could improve what you’re already doing. If you’re not using Memcache or APC yet, don’t bother – I urge you to take a look at Redis for a bunch of reasons.
First, Memcache is a key-value store only. You set a string value under a string key, and that’s it. With Redis, on the other hand, you have the luxury of several different types of data storage, including keys and values, but Redis also supports hashes, lists, sets and sorted sets.
An example to help explain why this is such a huge improvement. Say you have a big array of data, such as the kind that can come back from a web service request, like a parsed XML file or JSON packet. With Memcache, to store this in memory you have to serialize the data, often base64 encode the data, and then store it on the way in, and then to get a portion of the data back out again, you have to get the whole string, base64 decode it, deserialize it and then you can read from it. These extra steps needlessly chew up compute cycles.
With the same data object stored in a Redis Hash, for example, you can have instant access to the data stored in any key of the hash, you don’t have to grab the whole thing, deserialize it and all that mess. Just a single line of code, and boom, there’s your data. Much more elegant.
Another key reason Redis is superior to Memcache is that when you ask Memcache to store something, it’s in memory and that’s it. If your server goes down and you have to reboot, you have to repopulate your Memcache data over again. If your app has gotten huge, and your cache is huge, this can not only take awhile but puts a huge strain on your database server during this so-called “cache warmup” period. Unlike Memcache, Redis actually stores a copy of its data to a file on disk in the background, so if you stop and start your Redis server, it reloads everything automatically. It does this mind-blowingly fast, too, like millions of keys in seconds.
Finally, Redis supports master-slave configurations that you can use to build high-availability systems more easily. In the upcoming release (everyone is very eager for) Redis Cluster will support sharding out of the box!So, now that you want to dig in and start learning Redis, here are my…
Top 10 Redis Resources Online
NotesYou may be wondering about NoSQL and where Redis fits into this discussion. When people bring up NoSQL, I tend to think of MongoDB. Unlike Memcached and Redis, MongoDB is a general purpose document/object (think JSON) store that (strangely enough) allows you to use some SQL-like commands to retrieve subsets of your data. I think of Redis as a data structure server. You don’t use SQL to talk to Redis, so I guess it could be considered along with other NoSQL solutions. You can compare Redis to MongoDB by going to try.mongodb.org/
- Redis documentation: redis.io/commands
- Try Redis Online: try.redis-db.com
- Redis-DB Google Group List Archives: groups.google.com/group/redis-db
- Antirez (Redis developer Salvatore Sanfilippo’s) blog: antirez.com
- Recent blog posts about Redis: RSS Feed
- Q&A: stackoverflow.com/questions/tagged/redis
- The Little Redis Book – Just released openmymind.net/2012/1/23/The-Little-Redis-Book
- Slides from Redis Tutorial simonwillison.net/static/2010/redis-tutorial
- A Collection of Redis Use Cases www.paperplanes.de/2010/2/16/a_collection_of_redis_use_cases
- My GitHub Page. Chock full of Redis-related project forks. github.com/phpguru
- Bonus: Here’s a slideshow for a Redis 101 talk I gave if you’re interested.
Posted on February 2nd, 2012 No comments
SQL Transactions with Kohana 3 – Note: Transactions were added in Kohana 3.1
StackOverflow Questions tagged Kohana-3 – Look for answers by Kemo, Samsoir and the other Kohana developers
KohanaFramework.org/discussions – Official Kohana Framework user forum
Kohana 3 ORM Tutorials and Samples – Terrific example usage of Kohana’s built-in ORM library
Kohana 3.2 Complete Tutorial – Quickly documented on the site, but comes with downloadable sample application
Useful Kohana 3.2 Modules & Code – Here’s BadSyntax’s link list of useful Kohana modules (Kohana OAuth 2.0, Media Compression, Minion CLI Task Runner, Minion Tasks Migrations, Kohana 3 Project Template, Pagination, Manage Site View Assets)
Blogging about Kohana 3.2? Get the RSS Feed