The database is sometimes necessary to make your plugins function the way you want. From storing some simple options, to adding full tables with more data for the users to utilize, it is truly a tool that should be put to good use. Putting data in the database means you can query for it easily; it is just very convenient.
However, it comes at a price. A cluttered database isn’t very nice to maintain, and you have to make sure the user can uninstall the data stored by the plugin. And if that’s not enough, you need to decide where to save this data. Either you use the options table created by WordPress, a nice solution for smaller settings, or you create your own table within the database for the plugin only. The latter solution is probably better if you need to store a lot of data, but it extends the database in such a way that it may create issues with other plugins doing database things, should you want to integrate with them in any way. It also means that there is a part outside WordPress that needs to be backed up, and should you want to move the install the Export/Import method won’t cover the data.
So what’s best? Data in options, or in its own table? It is entirely up to you depending on what you need to store. My personal guideline is that settings should go in options, and if it is actual content or larger amounts of data, I’d consider the external table option. Just make sure you inform the user, and make sure that it is possible to clean up after uninstallation should it be necessary, and you’ll be fine.
One thing to consider when developing plugins is whether or not you want or need backwards compatibility. There are new functions and hooks added to WordPress all the time, and if you rely on the new ones, previous versions not featuring them naturally can’t run the plugin. That’s why you should be careful when using new features because they may just not work in older versions of WordPress.
However, it is not just WordPress functionality that changes; the system requirements have seen some revamps too. As of writing, PHP 4 is still supported, while most PHP developers agree that PHP 5 is a lot better. The basic premise should be to support the hardware that WordPress runs on, but sometimes that’s just not enough. You may need PHP 5, or want it enough to accept that hosts running PHP 4 will cause your plugin to not work, despite WordPress running just fine. When you walk down that route, be sure to output an error should someone try and run your plugin under PHP 4, when it really requires PHP 5. Technically, the same issue can apply to MySQL.
How far back you want to let your users go with your plugin is up to you. Since the addition of automatic updates, one can only hope that the updating frequency of the end users is higher than it was pre-auto updates, but a surprisingly large amount of blogs still run on old version of WordPress, which is bad news for developers and for site owners. After all, there’s a bunch of security issues and so on to take into account. You may also want to consider whether your plugin is original WordPress only, or if you will support the multi-user version, called WordPress MU. Many, but not all, plugins will work in both, so you should consider that as well.
WordPress MU is short for WordPress Multi-User, which is what powers Automattic’s hosted weblog service, wordpress.com. It is used to power multiple blogs at once, and while it shares a lot of code with the stand-alone version of WordPress that this article is focused on, it may not play nicely with your plugin. That being said, most plugins (and themes for that matter) will work with Word- Press MU. The only time you may run into issues is if you add tables to the database, and possibly play with the core tables.
WordPress MU can most easily be described as something of an umbrella that allows a super admin user (with its own weblog, the WordPress MU front page) manage other blogs created underneath. On wordpress.com anyone can create a weblog, but that isn’t necessarily the way a WordPress MU install works; you can just as well run it to power multiple blogs (like a weblog network, for example) and not let users register and/or create their own blogs.
As for the directory structure, you’ll recognize the WordPress in WordPress MU. The only real difference is the blogs.dir directory, which contains all the created blogs’ data, such as images and uploads and such. You won’t be using that much, since WordPress MU has a central theme and plugin management part in the main wp-content, just like you’re used to. You can download WordPress MU from mu.wordpress.org. You’ll find up-to-date documentation links there as well.
Our website is not responsible for the information contained by this article. Webworldarticles.com is a free articles resource thus practically any visitor can submit an article. However if you notice any copyrighted material, please contact us and we will remove the article(s) in discussion right away.
This article was sent to us by:
Jennifer I. at
05132010
1. Wordpress Plugins and Functions PHP
All articles in this directory are property of their respective authors. Additionally, read our Privacy Policy
© 2010 WebWorldarticles.com - All Rights Reserved. Partners: Gunblade Saga