[wp-hackers] Two new, long-overdue plugins to make your wordpress life a little easier...
mikeschinkel at newclarity.net
Mon Oct 31 15:26:03 UTC 2011
On Oct 31, 2011, at 5:35 AM, Otto wrote:
> <mikeschinkel at newclarity.net> wrote:> Why add Post Formats to
> WordPress core? Practically anyone can do the same with a custom
> taxonomy. Aye, the value of post formats is not in the implementation,
> its in the standard.
> Different case that I don't think applies here. The value isn't in the
> standard, because you're talking about loading custom configuration,
> which is inherently non-standard.
On this we disagree. (Isn't the first time that's happened. Won't be the last either. :-)
> You're wanting a way to load different configs based on parameters
> which will very likely be specific to your own setup. Anything core
> does in this regard isn't going to match your setup or needs
There are not an infinite number of ways to set things up. There are standard patterns we could identify and address, if people were open to it.
> And realistically, you're not talking about some epic level
> of code here. You're basically wanting to get the domain name,
> probably from the $_SERVER variable somehow, then to check for a file
> and include it if it exists. Like, probably 3 lines of code, but code
> which is going to be customized or different for any given
> individual's setup/workflow/design-pattern/etc...
To me that statement could not be more ironic. If it's not an epic level of code, then why not standardize it? (That's a rhetorical question because I know you are against it so I know you'll find a reason not to...)
> Custom configuration is exactly what the wp-config.php file is there
> for. It doesn't have to be just a few simple settings. I've setup many
> sites with some varied wp-config.php files in there for various
> reasons. Having it include some other file is not strange.
There is no need for a foreach() in programming languages because for() suffices. But language designers recognize there is a common pattern and rather than force the developer to be potentially tripped up by off--by-1 errors and to always need to index into the array language designers realized there was benefit to adding a higher level feature.
Yes, we can leave the burden of many things to the developer, but when a pattern can be identified and it is only "probably 3 lines of code" it seems either short-sighted or sadistic not to evolve WordPress to remove said burden from the developer, just like adding Post Formats removed that burden for their use-case.
BTW, as an example of value, Alex King's Post Format Admin UI plugin wouldn't have near the value it does if everyone were having to hack together their own solution for post formats. Having people build knowledge of a deployment standard in plugins and themes would have significant benefit, but nobody is going to do it without core standardizing it.
More information about the wp-hackers