Can you expand on the vulnerabilities? I’d be interested in learning more.
The reason we chose to use the meta table is quite straight forward. We have intended from the get go to make this plugin worpress.com / vip compatible, which does not allow new tables.
Thanks for the explanation. Well, I learn something new or two every day; I didn’t know wordpress.com’s VIP accounts don’t allow new tables. Makes sense if one thinks about sheer volume and the related complexity (maintenance anyone? shudder!) And of course, having them in mind it’s eminently logical to stash data into an existing table. Smart choice in fact, as I think that’s a USP that sets TEC apart.
Thing is, everyone and their brother mucks about in the xx-meta (post, user) tables; with several plugins* fiddling around in the same data table, it takes just a bit of bad luck to have an accident. What I mean is that you lose control exponentially over the integrity of “your” data when they’re stored and accessed in a common repository; you are more exponentially exposed to problems that originate elsewhere. With your own table you’re a little bit more safe from that.
Plus, there’s the “semantic architecture” argument I mentioned; although not entirely unrelated as species, having a different type of semantic data stored in the same data table defeats a bit the purpose of having a distinct “post metadata” table in the first place, which is intended for storing stuff related to the post (or page) itself; not or not necessarily different instances of a “post” (as is a calendar event in your design). To a certain degree, the “spaghetti architecture” resulting from the use of the same table for (very) different ends makes it easier to derail (reminds me a bit of messy clusters of extension cables and splitters with X-mas decoration lighting eventually going into the same outlet…)
However, I understand better now why you opted for using the post metadata table. Thanks again for the explanation.
*Added later: looking at the mindboggling sprawl of plugins (a good thing, in the balance) and especially the resulting combinations of all the various and sometimes truly exotic plugins out there really gives me pause, using a “common” post metadata table – it certainly makes me appreciative of the Automattic team’s initiative to offer a basic / core / canonical repository of plugins, to at least offer a minimal base of “stable” plugins for use by newbies…
Your concern is totally valid and plugin interference is a common issue. Most of the struggles we have found though seem to take originate from javascript rather than db conflicts.
If you look at the .com stats, they have close to 10 million blogs and 1.5 billion page views per month. With that load, I’d lock down everything I could while still leaving a touch of freedom. The fact that they allow plugins at all is impressive and run as smoothly as they do.
Out of curiosity – have you coded any plugins yourself? are you freelancing?
If only I could code my way out of a paper bag – with or without a gun pointed at me… Nope, I’m a language guy; my thing is more l10n and i18n related.
