[wp-hackers] Wordpress minor versions changing things for no
reason, why?
Mike Purvis
mike at uwmike.com
Fri Oct 12 07:24:35 GMT 2007
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 <otto at 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 <mike at 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:
> >
> > $cat_id = get_cat_id($_POST['cat_name']);
> > $post_cats = wp_get_post_cats('', $post_id);
> > $post_cats[] = $cat_id;
> > wp_set_post_cats('', $post_id, $post_cats);
> >
> > 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:
> >
> > $cat_id = (string)get_cat_id($_POST['cat_name']);
> > $post_cats = wp_get_post_cats('', $post_id);
> > $post_cats[] = $cat_id;
> > wp_set_post_cats('', $post_id, $post_cats);
> >
> > Draw your own conclusions.
> > _______________________________________________
> > wp-hackers mailing list
> > wp-hackers at lists.automattic.com
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> >
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
--
http://uwmike.com // http://googlemapsbook.com
More information about the wp-hackers
mailing list