Thinking about how I’d like to find posts.
A working but incomplete first iteration
I’ve played around with the first iteration of the post wrapper and was satisfied to a point.
This purpose of this first iteration was to plan the next one and, in this context, version 0.1.0
did succeed.
What’s missing?
Much of course but I will make a concrete example.
A note: this whole class system of post “augmentation” has its reasons fulfilled when used in custom WordPress installations (or plugins or themes) thar are not relying on default WordPress instantiated loops and vars; in the case below I’m using the wp-routes plugin to handle the displaying of a single page.
add_filter('wp-routes/register_routes', function(){
respond('GET', '/[:slug]', function($request){
$page = get_page_by_path($request->slug);
// not found, next route
if(!$page) {return false;}
// `tad_PageRepository` extends `tad_PostRepository`
$page = tad_PageRepository::create($page->ID);
// do something with the page data
<h1><?php echo $page->post_title; ?></h1>
// ...
});
});
What’s happening is that I’m querying the database for a WP_Post
object using the get_page_by_path
function, using a single property of that object to identify and create another object, a tad_Post
instance, in the $page = tad_PageRepository::create($page->ID)
call.
The second query to the database, the one sprung by the tad_PageRepository::create
method, will hit the cache but still it’s a computational overhead that should be avoided.
What’s missing is something evolved ORMs like Laravel Eloquent or Doctrine ORM offer: flexible find functions.
Ideally I’d like to have a function like this in my arrow
add_filter('wp-routes/register_routes', function(){
respond('GET', '/[:slug]', function($request){
$page = tad_PageRepository::find('first', array(
'post_name' => $request->slug)
);
// not found, next route
if(!$page) {return false;}
// do something with the page data
<h1><?php echo $page->post_title; ?></h1>
// ...
});
});
Possibilities
Possible more finding possibilities are to query the posts repository the same way a WP_Query
object could be initialized
// take the same query args as a `WP_Query`
$posts = tad_PostRepository::find('all', array('connected_type' => 'related', 'connected_items' => 23));
Allow for the use of meta values and terms in “transparent” ways
// allow for the use of meta properties
// `color` is a meta value, `category` is a taxonomy
$posts = tad_PostRepository::find('all', array('color' => 'red', 'category'=> 'new'));
Allow for the ad-hoc inclusion of other related objects
$posts = tad_PostRepository::find('all', array(
'color' => 'red',
'category' => 'new',
'include' => array('author', 'comments', 'related');
));
that should allow for code like this to be written
foreach($posts as $post){
$title = $post->post_title; // nothing different here
// `$post->author` is a `WP_User` object
$author_name = $post->author->last_name . ', ' . $post->author->first_name;
// `$post->category` is a term object
$category_name = $post->category->name;
$category_description = $post->category->description;
}
I will come up with more desirable use case and scenarios along the way.
Next
Iteration 2 will concentrate on the tad_PostRepository::find
metodd and its possibilities. Ample inspiration from the two framework implementations above will be taken.