Chip Bennett

I guess I don't get the pain point with custom post meta data

suffer core?

*aren't

add_meta_box() and its subordinates isn't that difficult to crank out in one-off situations like that

@Rarst one or two custom meta data keys? Just write the callbacks to handle them explicitly.

@Rarst "some extra inputs for a couple CPTs" - I would normally consider that use case (the same one I usually encounter) to be one where a framework would be far too heavy.

What is the need for a "custom fields framework"?

@kaiser have it in good shape, but letting it sit for a bit while I think about how to proceed from where it is

Finally! A fun question to answer: wordpress.stackexchange.com/a/142057/3966

@kaiser the moderating itself isn't a bad thing. There's a useful question and solution buried in there that needs to be brought out.

@toscho of course not! Far be it from me to overwork poor little bunnies!

am I wrong? Would the callbacks I had yesterday not become methods if the whole thing were wrapped up in a class?

My next step is to convert the whole thing to a class. Did I waste my time eliminating the callbacks, that would have been turned into class methods (that I would now have to re-create)?

@toscho how are they different from class methods?

@toscho I had everything broken out into callbacks, and got raked over the coals yesterday for it

@toscho $breadcrumbs['base_link']

@toscho the order is intentionally the same as template-loader.php

If there's a way to reduce the amount of code, I'm all ears

I don't understand. How is testing a class method different from/better than testing a callback?

how does that help? Asked another way: how is that any different/better than the callback functions that you didn't like?

How would you break it down, then?

Okay @toscho is this a step in a better direction? Not a class yet, but the main function is better abstracted: gist.github.com/chipbennett/10013478

That's why I'm trying to find the balance

@G.M. and that level of flexibility would be debated for five years as a core patch

@G.M. I think that's WAY too complex for what I'm trying to get into core

Not getting fixed, because some Plugins might break :/

@boscho there's already a ticket/patch for the issue - 21 months old, of course: core.trac.wordpress.org/ticket/21213

I think I'll patch it up and submit it. Thanks!

Would it be this? $type = preg_replace( '|[^a-z0-9-_]+|', '', $type );

This is pretty explicit intent to have a front_page_template filter name: return get_query_template( 'front_page', $templates );

how would the regex be constructed to allow for the underscore that is intended to be passed?

@boscho so that's a bug then, right?

so what's going on?

I see no underscore there

$type = preg_replace( '|[^a-z0-9-]+|', '', $type );

get_query_template() does this to $type:

But add_filter( 'frontpage_template', $callback ) does work

But if you try add_filter( 'front_page_template', $callback ), it doesn't wok

return get_query_template( 'front_page', $templates );

Front page template passes front_page as $type

get_query_template() applies a filter: apply_filters( "{$type}_template", $template )

Side note: is this a bug or a feature? svn.automattic.com/wordpress/tags/3.8/wp-includes/template.php

Yeah, I just see lots of complexity

I'll take a look at making it a class

let's get rid of paginate_links(), posts_nav_links(), etc.

@Rarst then why have any core template functions at all?

@Rarst because I have a vested interest in what mutually benefits Theme developers and end users

but core needs something

Heck, pull the Hybrid class into core for all I care

@Rarst "not theme-specific" is a key point: it's template-specific output that should have at least a basic core implementation.