[wp-hackers] Wordpress minor versions changing things for no reason, why?

[Jacob]

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.

Jacob Santos

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 <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
>>
>>     
>
>
>