Should WordPress plugins that make any database schema changes have a local database scheme version number?
The plugin README file has tags for Requires at least, Tested up to and Stable tag.
I’m suggesting that alongside defining the plugin version, and the three README tags, there should be a value for the schema. This means that plugin authors can explicitly note when their plugin is updating the schema.
Whether it goes in the main plugin file next to plugin version, or in the README file I’m not sure it makes any difference. But if we build in some hooks to trigger on schema version change then we gain two things. Firstly, developers like it as they can explicitly perform tasks based on schema versions and version changes. And secondly, users can be notified that the plugin is about to make schema changes. Which might encourage backups.
Having been playing around with WordPress Network (Multisite) plugins, mostly internal, not doing much that anyone else would be interested in having. During a plugin’s lifetime it goes through some critical points. The one you can’t avoid is activation. Many also experience deactivation or even deletion. Most will, at some point, be updated. for these critical points the plugin author may want to have certain critical events happen. Setting up options, creating databases, pre-populating meta data. And of course the reverse – deleting said litter.
A quick summary of the register_activation_hook() function:
It doesn’t work on multisite. Network activation does not trigger this function
Updating the plugin does not trigger it
It is triggered every time a plugin is manually re-activated
None of these are my desired behaviour. I usually write my own hook that checks if the plugin version has changed, and fire off my actions.
Which makes me wonder whether the function is out dated, and should be replaced a set of alternative functions. They could perhaps even be actions?
I spent over an hour trying to figure out the user’s workflow when wanting to add an uninstall hook to a WordPress plugin. I did eventually stumble across the answer, which once you know probably seems blatantly obvious. However, it wasn’t for me at the time.
Question: How to trigger the register_uninstall_hook() callback function?
Answer: Delete the plugin!
I spent a lot of my time looking for the uninstall link. Wondering if I was supposed to make my own. Not sure whether it being a Network Activated plugin made a difference. All the documentation and blog posts I could find just implied that it would all work out of the box. And, well, it does.
When you deactivate and then delete a plugin, it usually asks you for confirmation. With a plugin that has registered and uninstall hook, it adds some additional text. Personally I think that’s a little obfuscated, both to developers and to users. Maybe I’ll find the time to figure out trac and submit a patch for recommending further emphasis. Hopefully, I will find somewhere to mention it on the wordpress.org documentation site.
Daunted by all the hoops needed to get a theme onto wordpress.org, I thought I would opt for the plugin route instead. It would let me dip my toes in the pool that is the WordPress open source community. It was just meant to be a stepping stone, not actually a thing in itself.
How it came about
I brain-stormed, with myself, for about five minutes. My requirements were:
Custom post types
Complete solution (not an extension, something fairly trivial)
Simple and quick to understand (no confusion about what the plugin does)
That was it really. Took me about sixty seconds to think of “a glossary”. Another three minutes of searching to see if someone else had already done it. Several of the available glossary plugins at the time had not been updated for a while, others seemed obvious attempts to lead users in to a ‘pro’ paid-for version. And the rest did not appear to make use of custom post types. It seemed that my idea was just about unique enough (in execution) to permit an attempt. The last minute was spent coming up with a name. With glossary taken, I figured the simple thing would be to add the usual WordPress prefix. And so WP Glossary was born.
What I expected
Honestly? I expected WP Glossary to languish unused and alone. I figured that some people would try it out of curiosity, but ultimately move on to one of the other plugins available. It would leave me alone to just try stuff out. I mean, no-one is going to install the plugin on an actual active site. A site being used.
What happened then
Some of those crazy WordPress-using people out there decided to use my plugin. And to suggest ways to improve it. And point out bugs. Other people got involved in my plugin. Seriously, that really did blow my mind. It was interesting to see how they used WP Glossary, and to find out what they wanted it to do.
I still have quite a clear idea of what I want to achieve with my plugin. The simple custom post type approach is solid, but WP Glossary is still quite rough around edges. As well as my own goals, suggestions and ideas have come from the forums (and in comments on this site). And there are some performance (and other edge cases) to deal with under the hood. All these possible changes are refinements rather than additional features. I think the core of WP Glossary is sound as it is.
I thought I would blog a little about it, as I never, ever expected for the download counter to hit 10,000. I know that that isn’t 10,000 sites using my plugin, but it is a big enough number to show that I’ve written something that contributes back to the community. In my own small way. That has to be considered a success, right?
Plugins are an ever-moving thing in WordPress. As the internet and WordPress core evolves and moves on, so WordPress plugins come and go. About 18 months ago I blogged about The Life And Times of WordPress Plugins. This is a follow up, of sorts, looking back at my plugin usage, and trying to predict my future use.
This was a real must-have for my work. We have to use cases for media items: being able to group them and attaching meta data to them. A trivial example would be a list of sponsor logos with links to their websites. It now doesn’t get used that much. WordPress core has added the ability to assign taxonomies to attachments. And our sponsors data has grown more complex and become a custom post type. It may continue to fill a niche, but I think that much like scissors it has done the best it can: inspired WordPress core to improve.
I just can’t live without this plugin. I use it to create complex profiles for users. Lets say you want your speakers to be able to login and update their profile? Easy, use P2P to link a WordPress user to any number of speaker profiles. Now you have separation and control over the auth credentials and the profile data. Really useful. Now you want to assign your speaker profiles to a bunch of seminars. These relationship can be defined, built and controlled programmatically.
Not a free plugin! But I lost count of how much time (and money!) this has saved me (and therefore those that pay me). There some things about it that rather rub me the wrong way, but life without it would be full of boring manual form building. I have used other form plugins in the past, but they broke too easily. Being able to export and import forms seamlessly is a must.
A great compliment plugin to posts 2 posts. Being able to easily add custom fields to custom post types quickly and easily is not only just plain useful, but really speeds up development time. It is still quite clunky in places. I foresee that it will become slicker. And is possibly even a contender for being considered for absorption into WordPress core. With the emphasis on post formats in WordPress 3.6, and the implied requirement of different input fields based on type of some sort, I can see the attachment of meta data to varying post types being standardised.