Better late than never, however, had I read this thread of posts by David Peralty and Justin Shattuck back in Novemeber when they made them, I’d not have had a clue about what it takes to install a widget or plugin, much less the coding side of it all.
Since then of course, Joseph and I have heavily ramped up our efforts, and have really focused both on the clients we currently have LCHS.org as well as developing our own site concepts. In addition to take quite a time to “learn” just which application to use to build our sites upon, we’ve had to learn about the various platforms strengths and weaknesses. I for one can honestly say that I think I know a hell of a lot more today than I did back in November of ’06.
My latest ventures have been in trying to fully wrap my head around the concepts of widgets, and…
Then I was talking with Joseph about some navigation issues over at LCHS.org, and with that site and this one in mind, I realized that it would be very easy to solve the challenges by using the sidebar widgets and moving/playing with stuff until it was how we wanted it to be.
Well, what I discovered was that life is not all fun and games in the widget world, specifically as it relates to the the series of posts that prompted this one. I wanted to change the title on the search widget. Couldn’t do it without hacking the code. Yeah, it’s an easy one (as soon as you find the right darned place!), but code hacking is one of the stated challenges. Then, I wanted to use the category list widget. Easy enough, and I was able to change the name “Category” to something else. But where was the rest of the options that the core WP functions permit to adjust? Where was the ability to do all this stuff:
- orderby – Sort order by name
- order – Sorts in ascending order
- style – TBA
- show_count – Does not display the count of posts within each Category
- hide_empty – Does not display links to Categories which have no posts
- use_desc_for_title – Uses the Category description as the link title
- child_of – Shows the children (sub-Categories) of every Category listed
- feed – Does not display a link to the feed
- feed_image – Does not display a feed image for the Category
- exclude – Does not exclude any Categories from the displayed list
- hierarchical – Displays the children Categories in a hierarchical order under its Category parent
- title_li – Sets the title in a list (LI) as “Categories”
There was no access to those arguments which the WP-core function inherently has. Perhaps most people don’t know about these things. I didn’t know about them until I had to know about them. That’s groovy. That is what learning and growing is all about. The talk about making things “too complex” and having too many levels of controls, I feel, is a bit counter productive to the spirit of the functions themselves (in this particular widget case/example).
If the capability IS THERE, and someone has taken the time to write a “shortcut” (which really what all these add-ons are, right?) then I believe the onus is on that creator to make ALL those capabilities accessible. Otherwise, what is really the point? As an add-on creator, all you are doing is filling your (site) needs, and then “bestowing” the rest of us with your efforts.
Now, this isn’t meant to “rant and rave” by any stretch. However, if the core community isn’t going to make statements that support, guide and encourage, will it really be expected that the community at large succeeds? I’d ponder that for a while.
So, what’s it all mean? If something is going to be released to the community, take the few extra steps required to make it “least common denominator” acceptable. Take the time to comment your code; you are writing on your blogs anyways, and you are “thinking it” when you write out the code, document it. And like our friends over at 37signals, keep it simple, but don’t skimp on the controls if they are already inherently there. You don’t have to add every single function that exists, but if you are going to make a category/page listing widget give me the control to say what categories and pages are listed, et al.
The core designers had the fore thought to set up the requirements of how a plugin needs to be documented so it will actually plug into the WP-core so why not have the standard of commenting code, why not have the standard of an accompanying “readme.txt” file, why not require that plugins all be zipped/tar.gz’d etc.
It really is a thin line between slapping out some hacked up code that worked for you on your particular site install and boldly going the rest of the way and doing it the RIGHT!