Describe the solution you'd like
Models such as a Post or User model that can be extended for CPTs and such. A Model class would provide an expressive interface for interacting with the WordPress tables rather than using the fragmented and inconsistent APIs provided by core.
For example:
// current way
$post = get_post(1);
echo $post->post_title; // title
echo get_permalink($post->ID); // permalink
echo get_the_post_thumbnail_url($post->ID, 'post-thumbnail'); // featured image
// new way
$post = new Post(1);
echo $post->title; // title
echo $post->permalink; // permalink
echo $post->featuredImage('post-thumbnail'); // featured image
WP_User, WP_Term, WP_Post could all be expanded on in some way to reduce the need for global helper functions. A better naming convention could also be utilized ($post->post_name doesn't adequately describe "slug" for instance). Following from Laravel's Model class, accessors, mutators, casts and more could be utilized for simple development.
Describe alternatives you've considered
Using the WP APIs has some cognitive load to remember the names of functions, the accepted parameters (WP functions quite often accept multiple types for one parameter), the error handling and other quirks such as using global $post or requiring an ID to be passed. It is possible (obviously) to use the core functions but a Model class would be nicer to write.
Additional context
Custom tables could also possibly also extend the Model class. It may be required to have a base class and then WP "models" extending this so the underlying model is table-agnostic.
A DB query builder would be able to return results with the correct models, simplifying queries, result manipulation etc. For the sake of keeping the feature request a manageable size, I suggest building out the Model first - WP_Query can be piped through a transformer to hydrate the models in order to use the underlying models, and the a query builder can be implemented at a later date.
Describe the solution you'd like Models such as a
Post
orUser
model that can be extended for CPTs and such. AModel
class would provide an expressive interface for interacting with the WordPress tables rather than using the fragmented and inconsistent APIs provided by core.For example:
WP_User
,WP_Term
,WP_Post
could all be expanded on in some way to reduce the need for global helper functions. A better naming convention could also be utilized ($post->post_name
doesn't adequately describe "slug" for instance). Following from Laravel'sModel
class, accessors, mutators, casts and more could be utilized for simple development.Describe alternatives you've considered Using the WP APIs has some cognitive load to remember the names of functions, the accepted parameters (WP functions quite often accept multiple types for one parameter), the error handling and other quirks such as using
global $post
or requiring an ID to be passed. It is possible (obviously) to use the core functions but aModel
class would be nicer to write.Additional context Custom tables could also possibly also extend the
Model
class. It may be required to have a base class and then WP "models" extending this so the underlying model is table-agnostic.A DB query builder would be able to return results with the correct models, simplifying queries, result manipulation etc. For the sake of keeping the feature request a manageable size, I suggest building out the
Model
first -WP_Query
can be piped through a transformer to hydrate the models in order to use the underlying models, and the a query builder can be implemented at a later date.