[wp-hackers] wp releases : is it planned in any way ?
wordpress at santosj.name
Fri Sep 12 13:16:41 GMT 2008
Ah, I like to think of the WordPress API as a black box in which my
solutions do not involve modifying the core purpose of WordPress
functions to serve my ends. In programming, you are not always going to
have the advantage of being able to modify the library for which you
use, therefore it makes for almost disappointing practice to assume that
the author of the library you use will bow to your will, just because it
will make your life easier.
After looking it over again, it would be super easy to include the
taxonomy argument with little overhead and increase the power of a few
relatively general purpose functions. I can then agree that I should
withhold further judgment until I see a patch for which to critique. It
is not the way I would have went about solving the problem if it was me,
but I forget not everyone is a fan of torturing themselves.
> 2008/9/12, Jacob Santos <wordpress at santosj.name>:
>> Of the 9 line function body, you only need 2 lines to create
>> your own function. I'm not sure where you are getting 2000 lines of code,
>> but forcing the core code to dance around your modifications is not
>> something I would be happy about without good enough reason.
> I don't need the modification to actually get the categories of my own
> taxonomy. I need the modification for all the other WP functions to
> get the categories of my own taxonomy.
> Without the mod, I'd have to recode one or two dozens of (big)
> functions which start by $categories = &get_categories($r); and do not
> apply filters on it. Maybe not 2 000 lines of code, but surely like a
> 40ko futile copy / paste of functions, and conditional tags in all the
> templates files ( if(is_directory()) my_list_categories($args); else
> wp_list_categories($args); ).
> Copy pasting is not above my level, and time is not an issue (find and
> replace 'category' => 'my_category' ). But adding 40k of code, and
> almost making a fork of major WP functions is an issue regarding speed
> and future maintenance.
is_directory() actually does sound pretty good function. I would add a
prefix to any function you create that is uniform for your plugin,
myplugin_is_directory() and myplugin_my_list_categories().
>> Functions of that limited purpose
> woosh. did you count the occurences of get_categories() calls (front
> and back ends) ?
I should have said, "specific purpose", which is to get the category
taxonomy of /WordPress/, not every taxonomy in WordPress and plugins. If
it won't be that much more to add the taxonomy to the argument and allow
it to be used, it makes sense to want to allow those to be reused. Reuse
is a programming concept I agree with.
>> get_terms() is well flexible enough to allow you enough freedom to
>> employ in any fashion to create your own function for what you have in mind.
> Well, I'd like all these major WP functions to know what I have in my
> mind, but well..
That doesn't sound like good development practices. There are many
libraries that I wish would do thing differently, but hey, they aren't
going to change just because of one punk guy saying, "You should allow
unlimited or additional extensibility." It would make more sense to
create a generic function which do the dropdown, because I believe there
are several areas that offer that functionality.
So instead of widening the scope of specific functions for yet another
purpose, you are bloating those functions. Then again, for performance
reasons, in tests I've done creating another function to reduce
redundancy ends up increasing overhead from PHP having to create the
function stack, setup the variables and then exit the stack when complete.
I will say that the Plugin API has an upper limit of how many hooks that
can be performed before it takes a full second to perform those actions.
Depends on your system, but I do like my system because everything is
slower and I can actually see how long functions take relative to each
other. You might want to test the performance of your plugin, depending
on the size of it.
Well, for performance reasons, you can still create the generic dropdown
based on the code from categories, users, etc, but not use it in the
WordPress API. Have it just for plugins.
>> You can also create an wrapper around get_categories by using the 'include'
>> argument for get_categories(). If you get the IDs of the terms of your
>> taxonomy, you can include your specialized categories along with the
>> WordPress ones.
> my specialised categories don't mix with post categories. and fetching
> the correct ID for all categories call = twice the SQL load.
Indeed. I remembered too late that the WHERE clause might also include
>> You can also hook into the 'get_terms' filter and look for the 'category'
>> and 'link_category' taxonomies to add your taxonomy terms to.
> the get_terms filter is way too late in the function to do that. I
> mean, it is in the right position (just before the return), but it's
> after the query and after the sorting.
It would be at a cost to have to go through all of the get_terms
functionality just to replace it with your own. It would be easier and
at a lower cost to simply pass the correct taxonomy to begin with.
>> I mean, I not
>> sure exactly what you are trying to achieve or how, but there are several
>> ways around not doing anything to get_categories().
> Well, after DD32 thoughtful reply, a simple filter addition would do
> the trick, without compromizing the code.
Yeah, if your purpose is to make the other functions that use
get_categories more general purpose, then it seems that the action you
are preforming is one that is known before hand and can be passed as one
of the arguments. No filter, just allow the taxonomy to be set within
the $args parameter.
> Well I guess you have your answer now, don't you ?
No, my limiting factor is that I'm a zealot for my programming paradigm.
I don't agree with what you are trying to achieve based on one of my
principles for programming. I don't do things, because I'm limited by my
average IQ, well not always at least. I do it because I feel it is the
right way to do it.
It would be nice if WordPress was more flexible, but it would be at the
cost of time and performance. My fear is still that another is going to
come along and soon this and that does this and also that as well as
another several tasks it was not meant for.
The functions you point to are for presentation and in my programming
paradigm it is acceptable to recreate new functions for your specific
purpose or refactor existing presentation functions to allow for
additional reuse. From what you described, to me the solution is either
to 1) add filters to those dozen or so functions to allow for reuse (the
negative impact of performance is justified by only having the filter
where it is needed or 2) create a generic API for presentation layer and
allow reuse of it instead.
You will notice that I don't mention get_categories(). There are
disadvantages to everything. Mostly the time it will take increases with
those two, your solution would probably take less than 30 minutes to
complete whereas, the second solution would take several hours, plus
additional time for testing and writing test cases. Those are my ideal
solutions, but I doubt I'm going to implement them myself.
So you know, another one of my programming principles is that if you can
do something in five minutes verses 8 hours, then I'm going to go with
the five minutes solution first and put the "right" 4 to 8 hour solution
on the back burner. But you know, it is the weekend coming up, so if you
insult my intelligence further, I might just jump in to action to prove
you wrong. Whether or not I succeed is really not the issue at that
point. Also, probably not going to be committed since it would be an
overwhelming change and it is a little late in the development cycle. It
would take more debate than you know an additional three lines of code
More information about the wp-hackers