This is not a popular plugin, I'd guess it has only maybe a few hundred active users. Yet out comes WP 2.3, and I've got an inbox of emails from users annoyed that it's broken again, and by another Wordpress release that doesn't seem to justify itself with any significant new features or improvements.
I realise that ajax enhancements depend on things like markup structure which is impossible to set in stone, but I wish the devs could at least make an *effort* to not make trivial changes that might break this kind of functionality.
Here's my email on this topic from the last time, which didn't attract much attention:
Sorry for being confrontational; but perhaps a core dev or someone could link me to a page explaining any processes or policies regarding these things?
> another > Wordpress release that doesn't seem to justify itself with any > significant new features or improvements.
Are you kidding? I'm not even going to humour you with a list of the new features, improvements and bug fixes here as it will mean this thread going straight off-topic.
> I wish the devs > could at least make an *effort* to not make trivial changes that might > break this kind of functionality.
Back to the subject at hand, Mike, have you identified the particular changes in 2.3 that have caused these breakages? I'd like to know what they are. Are you sure they're trivial?
Unfortunately backwards compatibility with every plugin out there cannot be guaranteed. Indeed in some cases, plugin and/or theme compatibility is knowingly (but not intentionally) broken in order to advance and improve WordPress. If the WP devs were to hold back on changes in case they "might break this kind of functionality", then WordPress would not advance very much at all.
> This is not a popular plugin, I'd guess it has only maybe a few > hundred active users. Yet out comes WP 2.3, and I've got an inbox of > emails from users annoyed that it's broken again, and by another > Wordpress release that doesn't seem to justify itself with any > significant new features or improvements.
> I realise that ajax enhancements depend on things like markup > structure which is impossible to set in stone, but I wish the devs > could at least make an *effort* to not make trivial changes that might > break this kind of functionality. > ...
Sorry for being confrontational; but perhaps a core dev or someone
> could link me to a page explaining any processes or policies regarding > these things?
> Mike
Well, there's this page on the codex [1]. It's more of a general warning directed towards users that some plugins may not be compatible after an upgrade, and, while I realize that's not really what you were looking for, you (as a plugin author) could take it to mean that the "official" policy is that plugin authors need to keep up with the WP development if they don't want their plugins to break.
My best advice would be to follow WP development as closely as you can, and (if time permits) either fix the plugins prior to the WP release or at least put a notice up that advises users of the upcoming incompatibility.
Subscribing to this list is a big help in keeping up to speed with changes. I'd also recommend running a test instance out of the SVN trunk that you could to a quick update on as often as you like, so that you have a heads up as soon as a breaking change gets into the code base. In most cases this will be at least a month prior to that code being released, so it gives you some time to fix it.
I don't mean for that to sound insensitive and/or not helpful, but I'm not really sure what other options there are that would allow the project to make progress at a healthy pace.
> This is not a popular plugin, I'd guess it has only maybe a few > hundred active users. Yet out comes WP 2.3, and I've got an inbox of > emails from users annoyed that it's broken again, and by another > Wordpress release that doesn't seem to justify itself with any > significant new features or improvements.
> I realise that ajax enhancements depend on things like markup > structure which is impossible to set in stone, but I wish the devs > could at least make an *effort* to not make trivial changes that might > break this kind of functionality.
> Here's my email on this topic from the last time, which didn't attract > much attention:
> Sorry for being confrontational; but perhaps a core dev or someone > could link me to a page explaining any processes or policies regarding > these things?
On Fri, 12 Oct 2007 13:40:51 +1000, Jared Bangs <ja...@pacific22.com> wrote: > My best advice would be to follow WP development as closely as you can, and > (if time permits) either fix the plugins prior to the WP release or at least > put a notice up that advises users of the upcoming incompatibility.
I'd suggest testing with the beta versions at least (And keeping in mind that even then, it may change in the final beta releases) if you dont have enough time to follow Core Dev.
Unless you're only using WordPress API functions, you cannot be sure that the plugin will be forward compatible, Theres simply too many things which can change during development to maintain backwards compatibility with non-API functionality. WP Devs do their best to maintain that all API functionality stays backwards compatible with older releases, I dont think you can hope for more than that in any Product. _______________________________________________ wp-hackers mailing list wp-hack...@lists.automattic.com http://lists.automattic.com/mailman/listinfo/wp-hackers
On 10/12/07, John Blackbourn <johnbillion...@gmail.com> wrote:
> Back to the subject at hand, Mike, have you identified the particular > changes in 2.3 that have caused these breakages? I'd like to know what > they are. Are you sure they're trivial?
No, I'm not sure at all that they're trivial. But one thing that broke between 2.1 and 2.2 had to do with a css class name going from "the-list-x" to "the-list", an obviously wanton change. (And indeed, the next version after that change eliminated the dependency on it, by instead inserting a piece of markup via filter that I could rely on and hook into.)
There was another breakage between 2.1 and 2.2 that had to do with slight changes in the behaviour of wp_set_post_cats.
Jacob: I appreciate your willingness to help, but I haven't really got the time or inclination at the moment to debug this. Nonetheless, your post highlights the fact that it would be awfully nice to have a best-practices resource for plugin authors, which lists functions from most- to least-stable, and indicates the best way to do things like initialization.
Jared: I don't have time to religiously follow the WP trunk. My point is that for such a mature project, the Wordpress code seems to experience an awful lot of churn, and it makes the overall experience for casual plugin authors extremely intimidating and frustrating. Is there a release-cycle policy? What about restricting new versions with significant code change to a 6- or 8-month cycle, and only dropping bugfixes and security patches in the intervening time? Maybe even a special low-volume mailing list to announce new beta releases?
DD32: Where would I find a list of stable API functions? All I've ever been able to locate are off-site lists for hooks and filters and this page of zero-level beginner introduction <http://codex.wordpress.org/Plugin_API>. Is there a canonical list somewhere of "safe" functions that can be used by plugins and are guaranteed to still exist in the next point release?
On Fri, 12 Oct 2007 14:34:30 +1000, DD32 <wordpr...@dd32.id.au> wrote: > On Fri, 12 Oct 2007 13:40:51 +1000, Jared Bangs <ja...@pacific22.com> > wrote: > > My best advice would be to follow WP development as closely as you > > can, and (if time permits) either fix the plugins prior to the WP > > release or at least put a notice up that advises users of the > > upcoming incompatibility.
> I'd suggest testing with the beta versions at least (And keeping in > mind that even then, it may change in the final beta releases) if you > dont have enough time to follow Core Dev.
... not even then. 2.3 RC1 broke stuff that seemed to work fine up until that point (IIRC, this is when the post2cat et. al. tables were actually dropped). Unless you were following dev, you wouldn't have expected that. And the fixes plugin-side were certainly non-trivial. Following the betas gained you pretty much nothing in this case.
> Unless you're only using WordPress API functions, you cannot be sure > that the plugin will be forward compatible,
... not even then. I've had several API functions change behavior on me across WordPress major versions, and have the compatibility logic in my plugin code to prove it.
> Theres simply too many things which can change during development to > maintain backwards compatibility with non-API functionality. WP Devs > do their best to maintain that all API functionality stays backwards > compatible with older releases, I dont think you can hope for more > than that in any Product.
An API without test-grade documentation is no API at all. In some cases, it's impossible to tell a bug fix from a breaking change -- and in practice, the difference is almost nil. Some very interesting and subtle differences exist between the major versions of WordPress with regards to how some functions work.
So, what's left? Pretty much the only way to be compatible is to test, test, and test some more. It's a huge time commitment, a PITA, and otherwise an unpleasant mess. The alternative is to screw the users on the new version, OR screw the users who don't run the latest version (with the ultimate gravitation being towards the latter).
Looks pretty vanilla, right? Well, the change had to do with the fact that get_cat_id returns and integer, whereas wp_get_post_cats returns an array of strings. And wp_set_post_cats now (as of some recent change) expects an array of string-formatted numbers rather than arbitrary numerics, so that the corrected code looks like this:
> Jared: I don't have time to religiously follow the WP trunk. My point > is that for such a mature project, the Wordpress code seems to > experience an awful lot of churn, and it makes the overall experience > for casual plugin authors extremely intimidating and frustrating.
If I recall correctly, Shelley Powers said something similar on her blog, and a bunch of people jumped into the comment thread to agree with her. Don't open source projects typically commit to a road map, long before they reach the widespread use of WordPress?
> On 10/12/07, John Blackbourn <johnbillion...@gmail.com> wrote: >> Back to the subject at hand, Mike, have you identified the particular >> changes in 2.3 that have caused these breakages? I'd like to know what >> they are. Are you sure they're trivial?
> No, I'm not sure at all that they're trivial. But one thing that broke > between 2.1 and 2.2 had to do with a css class name going from > "the-list-x" to "the-list", an obviously wanton change. (And indeed, > the next version after that change eliminated the dependency on it, by > instead inserting a piece of markup via filter that I could rely on > and hook into.)
> There was another breakage between 2.1 and 2.2 that had to do with > slight changes in the behaviour of wp_set_post_cats.
> Jacob: I appreciate your willingness to help, but I haven't really got > the time or inclination at the moment to debug this. Nonetheless, your > post highlights the fact that it would be awfully nice to have a > best-practices resource for plugin authors, which lists functions from > most- to least-stable, and indicates the best way to do things like > initialization.
> Jared: I don't have time to religiously follow the WP trunk. My point > is that for such a mature project, the Wordpress code seems to > experience an awful lot of churn, and it makes the overall experience > for casual plugin authors extremely intimidating and frustrating. Is > there a release-cycle policy? What about restricting new versions with > significant code change to a 6- or 8-month cycle, and only dropping > bugfixes and security patches in the intervening time? Maybe even a > special low-volume mailing list to announce new beta releases?
> DD32: Where would I find a list of stable API functions? All I've ever > been able to locate are off-site lists for hooks and filters and this > page of zero-level beginner introduction > <http://codex.wordpress.org/Plugin_API>. Is there a canonical list > somewhere of "safe" functions that can be used by plugins and are > guaranteed to still exist in the next point release?
> [...]Is there a release-cycle policy? What about restricting new versions > with > significant code change to a 6- or 8-month cycle, and only dropping > bugfixes and security patches in the intervening time? Maybe even a > special low-volume mailing list to announce new beta releases?
There is a release schedule, and it can be found here:
> I'm not a frequent participant on this mailing list, but I'm > frustrated once again that the WP 2.3 release has broken my plugin: > ... > Sorry for being confrontational; but perhaps a core dev or someone > could link me to a page explaining any processes or policies regarding > these things?
Keeping up with the changes between versions can be difficult - but the core devs cannot test every single plugin while making changes - nothing would ever get done.
In general we try and preserve the api for plugins.
If you want an easy way to keep track of WordPress development without having to spend a lot of time reading through every change you may be interested in my new weekly digest posts on http:// westi.wordpress.com/
wp_set_post_cats was deprecated in June of 2006, as of version 2.1 (I think, bit uncertain on the version).
What likely broke your code here in 2.3 was the change to the terms system, where cats and tags got combined. Unfortunate side effect, but few people check deprecated code because the core code no longer actually uses it.
The problem is how do you know if you're using deprecated code? I mean, your plugin is clearly still using it, even though it's been deprecated for more than a year. This sort of problem might be avoided sooner if changes like this one were put into place: http://trac.wordpress.org/ticket/4361
If the user was notified of plugins using deprecated code, then it would encourage authors to change sooner rather than later. I realize that stability is important for plugin authors, but I don't think it should come at the price of discouraging innovation in the core code either.
> Looks pretty vanilla, right? Well, the change had to do with the fact > that get_cat_id returns and integer, whereas wp_get_post_cats returns > an array of strings. And wp_set_post_cats now (as of some recent > change) expects an array of string-formatted numbers rather than > arbitrary numerics, so that the corrected code looks like this:
Hmm, yes. Well, the initial release of this was August 2006, meaning I probably developed the proof of concept a few months before, which would have been prior to the moving of that function to deprecated.php. (There's something fundamentally broken when I'm discovering the functions to call by using someone's phpXref installation...)
How about just having a option for "Dev Mode", which would pop up warnings for deprecated function calls, type mismatches, and any other weirdness of that kind? If there was a centralized resource for plugin authors (rather than a firehose mailing list and a wild-west wikipage), it would be possible to advertise such a feature.
> If the user was notified of plugins using deprecated code, then it > I realize that stability is important for plugin authors, but I don't think it > should come at the price of discouraging innovation in the core code > either.
Absolutely not. You guys need to be able to refactor and clean up the codebase and so-on. My point is just that the project as a whole suffers from the lack of resources available to help people extending WP. A good start might be a published set of the top fifty most "stable" functions, an explanation of what they do and any caveats, and links to similar functions, with explanations of why the stable function is the superior one to use.
> wp_set_post_cats was deprecated in June of 2006, as of version 2.1 (I > think, bit uncertain on the version).
> What likely broke your code here in 2.3 was the change to the terms > system, where cats and tags got combined. Unfortunate side effect, but > few people check deprecated code because the core code no longer > actually uses it.
> The problem is how do you know if you're using deprecated code? I > mean, your plugin is clearly still using it, even though it's been > deprecated for more than a year. This sort of problem might be avoided > sooner if changes like this one were put into place: > http://trac.wordpress.org/ticket/4361
> There may not be a perfect answer to this one.
> On 10/12/07, Mike Purvis <m...@uwmike.com> wrote: > > > I'd like to know what they are. Are you sure they're trivial?
> > Okay, ready for it?
> > Something changed between 2.2 and 2.3 that made this code stop working:
> > Looks pretty vanilla, right? Well, the change had to do with the fact > > that get_cat_id returns and integer, whereas wp_get_post_cats returns > > an array of strings. And wp_set_post_cats now (as of some recent > > change) expects an array of string-formatted numbers rather than > > arbitrary numerics, so that the corrected code looks like this:
On Fri, 2007-10-12 at 12:30 +1000, Mike Purvis wrote: > I realise that ajax enhancements depend on things like markup > structure which is impossible to set in stone, but I wish the devs > could at least make an *effort* to not make trivial changes that might > break this kind of functionality.
I am greatly shocked by the attitude you have, but I do not want to pollute with flamewars, so I will politely point you to these links, which appeared on the planet feeds aggregated on every single WordPress dashboard during September:
A lot of the documentation was written by the community and devs. I think WordPress offers a great experience from its lack of "professionalism." It is great learning experience and work experience to write phpDoc comments/unit tests/DocBook type documentation. I have not tried too many web applications, but it can be fun at times to take advantage of the situation and jump in and write the parts that are missing.
Actually, I was contemplating lately the same thing that the codex, while it offers good information, doesn't have a clear table of contents and difficult to wade through. Recent enhancements to DocBook rendering, might make it worth while to take up the long, tedious, I'll rather you stab me multiple times type of work process of taking parts from the codex and compiling such a book. It would be nice to have both an end user docbook and a developers docbook for such things as writing plugins/themes and hacking the core.
For the function list, if all of the functions were phpDoc-umented, then you would get such a list. That is also a boring and slightly difficult process. Adding phpDoc comments to the taxonomy really taxed my mind. Some of the functions were easy, but the big long one with many different branches is going to need a long and concise phpDoc. Even then, I forgot to include the "@since 2.3" might help, because people who join the community in the future would know that that code was added in WordPress 2.3. phpDoc would also allow for telling which functions were deprecated and what version.
Good stuff, if your focus is learning more about writing proper documentation/comments and unit tests. I'm having a blast (when I'm not clawing my eyes out). Pain can be a good thing to inflict upon yourself when others will benefit. You know the process can be tortuous but the end result is to die for.
Mike Purvis wrote: > Hmm, yes. Well, the initial release of this was August 2006, meaning I > probably developed the proof of concept a few months before, which > would have been prior to the moving of that function to > deprecated.php. (There's something fundamentally broken when I'm > discovering the functions to call by using someone's phpXref > installation...)
> How about just having a option for "Dev Mode", which would pop up > warnings for deprecated function calls, type mismatches, and any other > weirdness of that kind? If there was a centralized resource for plugin > authors (rather than a firehose mailing list and a wild-west > wikipage), it would be possible to advertise such a feature.
>> If the user was notified of plugins using deprecated code, then it >> I realize that stability is important for plugin authors, but I don't think it >> should come at the price of discouraging innovation in the core code >> either.
> Absolutely not. You guys need to be able to refactor and clean up the > codebase and so-on. My point is just that the project as a whole > suffers from the lack of resources available to help people extending > WP. A good start might be a published set of the top fifty most > "stable" functions, an explanation of what they do and any caveats, > and links to similar functions, with explanations of why the stable > function is the superior one to use.
> Mike
> On 10/12/07, Otto <o...@ottodestruct.com> wrote:
>> wp_set_post_cats was deprecated in June of 2006, as of version 2.1 (I >> think, bit uncertain on the version).
>> What likely broke your code here in 2.3 was the change to the terms >> system, where cats and tags got combined. Unfortunate side effect, but >> few people check deprecated code because the core code no longer >> actually uses it.
>> The problem is how do you know if you're using deprecated code? I >> mean, your plugin is clearly still using it, even though it's been >> deprecated for more than a year. This sort of problem might be avoided >> sooner if changes like this one were put into place: >> http://trac.wordpress.org/ticket/4361
>> There may not be a perfect answer to this one.
>> On 10/12/07, Mike Purvis <m...@uwmike.com> wrote:
>>>> I'd like to know what they are. Are you sure they're trivial?
>>> Okay, ready for it?
>>> Something changed between 2.2 and 2.3 that made this code stop working:
>>> Looks pretty vanilla, right? Well, the change had to do with the fact >>> that get_cat_id returns and integer, whereas wp_get_post_cats returns >>> an array of strings. And wp_set_post_cats now (as of some recent >>> change) expects an array of string-formatted numbers rather than >>> arbitrary numerics, so that the corrected code looks like this:
> ... take advantage of the situation and jump in and write the parts that are missing.
See, I thought about this. But there's still the fundamental problem that I have no idea what bits of the code will still be here in six months. I'm not going to invest 50+ hours careful crafting documentation to help novice plugin authors, when the next version is probably going to break it all again. That's half the problem with the codex... even what *is* there is mostly outdated! The fact that the core devs don't take documentation, consistency, and unit-testing seriously is a significant point in the argument about whether Wordpress is a business-ready platform or just a toy.
Anyhow, I'm not really interesting in debating a lot of stuff or flaming back and forth; I just wanted to share my impressions as a developer interacting with the Wordpress codebase and community. Thanks for your time.
I submitted a patch to raise user_errors() when someone uses a depreciated value. If we make it a standard habit when coding plugins to set the debug mode on, then you'll know if your plugin is using depreciated code.
Jeremy Visser wrote: > I am greatly shocked by the attitude you have, but I do not want to > pollute with flamewars, so I will politely point you to these links, > which appeared on the planet feeds aggregated on every single WordPress > dashboard during September:
It's also worth mentioning that the low-volume WordPress main blog had 5 posts about 2.3 prior to its release:
Travis Snoozy wrote: > ... not even then. 2.3 RC1 broke stuff that seemed to work fine up > until that point (IIRC, this is when the post2cat et. al. tables were > actually dropped). Unless you were following dev, you wouldn't have > expected that. And the fixes plugin-side were certainly non-trivial. > Following the betas gained you pretty much nothing in this case.
This is false. Anything that relied on direct SQL to the category tables would have been broken since the first beta, as those tables were no longer updated or used by the core code. The only thing that RC1 would have changed is you'd get a "table not found" error.
However the tables had not been updated or used for several versions before that, and if you didn't notice then you must not have been using them that closely.
> Travis Snoozy wrote: > > ... not even then. 2.3 RC1 broke stuff that seemed to work fine up > > until that point (IIRC, this is when the post2cat et. al. tables > > were actually dropped). Unless you were following dev, you wouldn't > > have expected that. And the fixes plugin-side were certainly > > non-trivial. Following the betas gained you pretty much nothing in > > this case.
> This is false. Anything that relied on direct SQL to the category > tables would have been broken since the first beta, as those tables > were no longer updated or used by the core code. The only thing that > RC1 would have changed is you'd get a "table not found" error.
> However the tables had not been updated or used for several versions > before that, and if you didn't notice then you must not have been > using them that closely.
It's a half-truth, hinging on the definition of "seemed to work fine" and the level of investigation done. The litmus test is generally "does my plugin activate." The bizarro behavior is there, but it generally takes a little more to notice it. Going down in flaming "OMG where's the database" errors is a much clearer indication that something's broken, and that didn't happen until RC1.
The only reason I mention it in these terms is because this topic (something not "breaking" until RC1) happened on the wp-testers list already[1].
Matt Mullenweg wrote: > Jeremy Visser wrote: >> I am greatly shocked by the attitude you have, but I do not want to >> pollute with flamewars, so I will politely point you to these links, >> which appeared on the planet feeds aggregated on every single WordPress >> dashboard during September:
> It's also worth mentioning that the low-volume WordPress main blog had > 5 posts about 2.3 prior to its release:
Yeah, that and I helped push the fact that THIS needed brought BEFORE the release too. I guess it goes to show no matter how far in advance the warning(s) are, people just don't read them or care about "them"... The warnings were posted on the bulletin boards in advanced to wake up plugin authors and such about various changes, and the possibility of plugin breakage... It's not the "developer's fault" ...
