[wp-hackers] Two new, long-overdue plugins to make your wordpress life a little easier...

Mike Schinkel 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
> precisely. 

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[1] 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.

[1] http://alexking.org/blog/2011/10/25/wordpress-post-formats-admin-ui

More information about the wp-hackers mailing list